Re: Fully encapsulated executable files with support...

[Felix Bellaby <felix pooh u-net com>]

Robert M. Ellsworth wrote:

> What you're really talking about is encapsulating runtimes into every
> file. This can be done, but making it cross-*NIX or cross-platform
> compatible will be a bitch-and-a-half. I think a better idea is to
> insert tag data into the file or its metadata which could be accessed
> by 1) intelligent-agent code running on the target system, and/or 2)
> applications (yes, applications -- dedicated program fragments which
> are optimized to handle general filetypes or functions called from
> files, in an appropriate manner).
> 

Not at all. This is not how any object orientatied system I can think of
works. What you do is define a type for the data (a class in C++) and
then store the code to implement its functionality within a class
object. You can see this going on in the gtk code when each widget has a
class struct which holds the function pointers with implment its
functionality.

What I am suggesting is that the mime type (or whatever) of the file is
used to search for the applications  (or other executable code) that
exists on the system and a summary is provided for the user.

The gmc already does this to a very limited extent by presenting you
with command prompt from the "Open with" menu item. This should improve
to become a menu of appropriate executables dressed up with mnemonic
names (as in the panel menu) once the file to application mechanism is
in place.

However, giving the user a list of executables may still be short
changing them. What they would really like would be a list of things
that they can do to the file. Again, the gmc already does this to a
limited extent: you can view files. However, there are a lot of other
things you can do to files and the menu of executables approach means
you have to know which executable does what, load the thing up,
remmember how to do it, do it, and close the executable.

Imagine the following scenario: you want to send a short patch to
"fred". At the command line you might type:

diff x/ y/ | mail fred

Now, unless the gmc has a special internal facility for doing this, the
GUI forces the following approach: select one of the directories, open
it with an application, issue the application specific commands for
making a diff, save the diff to a file, select the file, open it with an
email application and send it to fred. Of course this becomes slightly
easier if the applications are already running or can do diffs and email
but the picture I paint is far from impossible.

Imagine instead that you select both files in the file manager, select
diff from the right click menu (holding down a key to indicate piped
output) and then select mail from the same menu. Or, alternatively, you 
select diff then drag and drop the pipe onto an icon of fred.

The code to do the diff and mail are already on your system. All we are
talking about is how you access it.