Re: 2.6 digressions [was Re: release notes pimping [and some random thoughts on 2.6]]

[Maciej Stachowiak <mjs noisehavoc org>]

On 03Aug2003 12:35AM (-0400), Jonathan Blandford wrote:
> Luis Villa <louie ximian com> writes:
> 
> > >  - preferred applications spec that works cross-desktop
> > >    (easier if we have cross-desktop IPC system like dbus)
> > 
> > Possibly a dumb question, but if mime stuff works correctly, why do we
> > need the concept of 'preferred applications' at all?
> 
> I'm not 100% sure what a 'preferred applications' spec is, but I can try
> to guess what Havoc meant here.  Basically, there's a difference between
> the protocol you use to get to a file, and the way you handle the file.
> It's kinda messy, really.  Do you want to open the URI:
> http://www.gnome.org/~jdub/images/pirate.jpg with eog or epiphany?  Both
> will handle that, but the file itself is an image/jpeg.  We may be able
> to come up with a good solution for this case, but things like picking
> the mailer (for mailto:), terminal etc. are also problematic.
> 
> I don't I'm particularly comfortable with the mime stuff as it is
> providing this.  It basically provides a way to map from a particular
> file to a mime-type, and from a mime-type to an app.  It doesn't provide
> a good way to map to a task.

Is "task" vs. "app" the main problem here? It seems like in the
examples you gave, the problem is that URI scheme must be considered
in addition to, or even instead of, MIME type.

In the original Nautilus design for selecting components, we had three
different ways for a component to claim handling of a URI:

1) Claim to handle an entire URI scheme, regardless of the type of
data at the other end, and indeed, regardless of whether there is such
a thing as data at the other end. This is perfect for URI schemes like
"mailto:"; and "telnet:". If a component with a claim of this type was
the preferred one for the scheme, then no attempt would be made to
even determine the type.

2) Claim a file type regardless of what URI scheme it came from. This
is good for connecting types like "image/jpeg" to a network-aware
image viewer.

3) Claim any of several types as long as they come from one of a
particular list of URI schemes. 

(We also had special handling for directories based on the types of
files in the directory, but I don't think that is relevant here).

At first glance, it almost seems like you want to handle "http:" with
claims of type 2 or 3, so if you click on an http link to an image, it
shows up in your image viewr instead of your web browser. In practice,
this has a major drawback in terms of performance. You can't decide
what app (or component) will handle a particular type without
determining the type, which means actually connecting to the server
and starting a load. This means potentially a huge delay before the
right app is launched.

It may be that in the end, due to performance considerations, it's
better to just let the web browser handle all "http:" URIs, and
display them inline or download and pass off the data to another app.

That's essentially what happens on OS X - file type is only really
considered for "file:" URIs, and all others are mapped solely by
scheme.

Of course, this picture is muddied a bit by the fact that on OS X, the
strategy for network filesystems like WebDAV or FTP is to mount them
and access them via the filesystem namespace, rather than a
client-side solution like gnome-vfs. I can see how this would change
the tradeoffs significantly.

Regards,
Maciej