Re: [Summary} Meta-data/filesystem-encapsulation

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

Let me rehash the point I am trying to make because it is rather
different slant on file types than GNOME seems likely to adopt.

GNOME is providing a number of interfaces which application programmers
can use to write applications. These interfaces are not directly visible
to the user though their use has implications which the user can see
(appearance and operation of dialogs, embedding of documents etc.).

This contrasts with the interfaces to functionality in the GIMP where
the influence of the procedure database is clear in the menus, the
scripting language and the programming interface used by plugin writers.
Here the end user shares much of the development environment with the
hackers (and can share it all fairly easily).

I think this is a healthy environment for all concerned. It would be
nice if GNOME generated the same ease of access to the functionality of
the environment without requiring users to step inside applications to
gain access. Thus, you could select an image in the file manager, right
click to get a menu offering the GIMPs plugins and display it on the
root window without actually starting the application.

In order to make this possible the 'file' manager has to be able to
access that functionality with the same ease that the user interface on
the GIMP accesses its functionality. This will not happen unless the
functionality is made public by being exported out of the applications.
CORBA offers the means to do this by replacing applications with
servers.

What are the merits of not starting an application? Well, the user gets
a consistent environment and the programmer does not need to write the
code necessary to start up an application! Somebody else can come along
and create a new interface to the code or use it in some other task.
Some applications already make their functionality available through
libraries. Would not it be nice if they all did?

There are obviously limits on how far this can work. One can have a
dialog which allows you to run a text buffer through awk but fine
editing and data entry is not feasible without opening windows. However, 
there remains no reason why the creation of views and their editing
should change the environment the user has chosen in the way that
entering applications tends to do. 

Trying to cater for every type of operation that the user might want to
perform on every type of file would be impossible within a closed file
manager. However, a file manager which accomodates plugins based on file
types can offer whatever functionality the user has installed.

A model which associates files with applications can not hope to provide
this functionality. Instead, files (and objects in general) need to be
associated with the methods that can be applied on them. This is the
intuitive model in any case. No one associated printed documents with
WordStar before it was released and almost no one associates them with
it anymore. What people associate with printed documents is editing,
printing, etc.

Now, I dare say there are a host of ways in which files could be
associated with methods but I think CORBA would be quite a sensible one
to adopt. CORBA seems to be intended to provide an open approach to
accessing object methods. The fact that companies writing large
applications have not given end users access to CORBA in that way may
tell us more about the motivation of the companies than it tells us
about the merits of the idea.

The GNU community has no axe to grind in supporting large applications
(apart form Emacs :). I think it would be nice to apply any part of the
functionality available on my computer at any time without loading up an
application. This is what I try to do at the command line. I would also
like my code to be accessible to all and sundry.

If this all sounds like a bit of a pipe dream then you are starting to
understand what I am talking about. Existing computer environments do
not offer this kind of interface to end users. Developers have access to
libraries containing useful functionality but they use this within their
programs and present the end user with something all together different.

Of course, most end users have no interest in accessing most
functionality. BUT YOU ARE END USERS!! What gives developers the right
to decide which parts of their software are accessible to others?

I realise that many of the merits of this approach will take a long time
to realise and that many can be achieved by other means. However, I
think it is worth exploring. I would like to see GNOME breaking new
ground as much as possible.

Felix

NOTE BENE: in this discussion I am referring to the dynamic interface to
methods in CORBA. Obviously the file manager can not know which methods
will be associated with a file on a particular system at compile time.