Re: RPM and Corba/GNOME

[Stephanos Piperoglou <sp249 cam ac uk>]

On Mon, 23 Feb 1998, Miguel de Icaza wrote:

>    In any case the file manager would provide some kind of
> browse-capability for the available packages, but any further
> operations would be handled by an external program (actions can be
> trivially added for the file system as an external program).  So,
> starting work on the program that handles all of those extra features
> makes sense.

Basically I think it would be a good idea to think modular here. CORBA
(though I'm not very familiar with it) should give you a basis to operate
on; but I think it is imperative to get a desktop which deals in the
following stages:

(1) Resource location (ideally, I think, URI based... there are URL schemes
out there for everything from HTTP to geographical location). We get a
description of the object. In the form of something (CORBA spec? URL?)

(2) Resource Retrieval. The system parses the location and fires up an
approporiate retrieval mechanism (http, ftp, local file access, nfs,
whatever) to get the resource.

(3) Resource typing. An alternation of external description
(filename/extension, MIME type etc.) or, failing that, magic number
detection to map the resource to a certain application.

(4) Resource handling. Depending on wether we want a view, an edit, a move,
an embed or whatever we fire up (or communicate with) the appropriate
application in the appropriate way.

This four-stage handling of everything would give unprecedented power to
user, sysadmin and developer alike. The user could use a unique URI input
mechanism (command-line or browser-based) to be able to view or edit any
resource. Since each stage is configurable seperately, you could seamelesly
integrate this into existing standards that aren't GNOME-friendly (yet). A
user could request a text file, for instance, via http, and get the option
to view it with Netscape, on an xterm with less, load in on Emacs or even
pico, or whatever other actions he wishes to define. The sysadmin would be
able to configure each stage seperately without too much hassle, the
developer will be able to communicate with each seperately depending on his
needs, as well as have a wealth of tools ready for most tasks; instead of,
say, writing his own SQL interface for his application, he will write an SQL
retrieval mechanism for the Resource Retrieval, add a Resource Handler for
SQL and then simply call for them when he wants them in his program. Talk
about minimizing overhead.

This will HUGELY decrease the amount of tools you'll need to write, HUGELY
simplify the process of a number of things (ex.: a GNOME web browser now
need only be an HTML user agent; the HTTP etc. stuff will be taken care of
by the system describd above), will stay in line with the Unix philosophy
(draw a vague analogy to "Linux for a kernel, GNU for OS tools, X for a
graphical environment, GNOME for a desktop and GIMP for an app" - all
completely seperate yet seemlesly integrated) and will be very easily
implemented. Not to mention an integration with CORBA that will give "drag
and drop" a whole new meaning!

This would end the debate about "what should our filemanager look like",
"what should our web browser do", "what would our image viewer do" and so
on. Most of the implementations of these tools tend to cut vertically into
the problem, attempting to do too many things at a time. An example is
Emacs, which although almost a complete system for just about anything on
its own, fails to integrate smoothly with other tools that might want to
take over part of its job. What I propose to do is analyse the problem into
its actual component parts and tear it apart a step at a time.

For examples of a similar philosophy, already implemented:

- inetd, that maps TCP/IP services to ports, never caring about what these
services do.
- modern day browsers, that use various retrieval mechanisms (most only
file://, ftp://, http://, mailto: and https://, but that doesn't mean we
couldn't build on that) and either handle it themselves or launch a relevant
app.
- MacOS, which uses dual Magic Numbers for each file; one for file type, one
for application to be launched.
- Windows (*sigh*) that has a very crude implementation of this thing with
the whole OLE thing which was recently linked to MIME typing and using the
same client for http-retrieved and locally-retrieved data.

I think this would put things into great perspective.

-- Stephanos Piperoglou -- sp249@cam.ac.uk -------------------
All I want is a little love and a lot of money. In that order.