Ideas for Integrating The Document-Oriented Web into GNOME

[Alex Jones <alex weej com>]

Try disabling the http URI handler for GNOME.
<gconf:///desktop/gnome/url-handlers/http/enabled>

When you click a link to a PNG image, EOG starts up. Click a link to an
M3U file, and Totem starts up. What happens, is that GNOME-VFS
determines the MIME-type of the target file with a HTTP HEAD request,
and, exactly the same as with local files, automatically starts the
preferred application with that URI.

This hack is definitely rough and ready, what is needed to bring this
idea truly to life is:

     1. An "open URI/location/whatever" button/text entry somewhere easy
        to grab on the panel. As it happens, deskbar uses gnome-open
        when you type a http URI, so this kind of works. The same cannot
        be said, however, of file URIs. 
     2. A simple web page viewer, sans-location entry. Something that
        embeds Mozilla and calls gnome_vfs_show_url on any
        click-throughs. 
     3. A favourites system, allowing you to bookmark favourite web
        pages, pictures, sound files, spreadsheets, documents, web
        folders (dav/ftp), etc. all *by URI*. One click should invoke
        the file-open process.
     4. A UI for user-feedback and confirmation. When clicking links in
        IM conversations or opening a resource by URI, the user should
        be prompted with both feedback when the file is taking a while
        to determine the file type of, and also basic information about
        the file. E.g., Jane sends me a link to
        <http://herwebsite/somepicture> I have no idea what that is, so
        when I click it I should be told that "This is a JPEG image of
        size 534 KiB." I should be asked "How would you like to open
        it?" and be given a list of capable applications from XDG.
        Optionally, we could detect that if the resource is not on local
        storage (i.e. its URI scheme is not "file"), we can prompt the
        user to save it, and invoke a transfer. Preferences should be
        remembered if requested. For example, I don't want to be
        prompted to open a web page every time I click a link.
     5. A "navigation trail" system, whereby clicking links from one
        thing to another (e.g. Jane -> Her Picture) will be saved in
        memory somehow. Applications can then find out how the user
        arrived at that document, and implement a "back to where I came
        from" button. I think this is vastly superior to classic
        "back-forward" navigation, as more and more often, our behaviour
        of browsing the web does not fit that model. Kind of clashes
        with the Spatial paradigm when you open one file from two
        separate origins, but I'm sure we can think of something clever.
     6. More file-opening applications supporting a "Save As" action.
        E.g. Totem. When I click a link to an Ogg film on my friend's
        website, if I tell Totem to fire up, I should still be able to
        save the file to a new location without having to invoke the URI
        open prompt again.

What this effectively does, is gives us a "My Favourite Stuff" feature,
where you can put almost anything that is addressable via a URI. (Yelp
pages, anyone?)

It also dissolves the concept of a web browser into the desktop
platform, which I think is a radical but important step. Why have two
platforms? If I open an image/svg+xml on my desktop, it opens in EOG. If
I open one in a browser, it opens in the browser's helper application.
Though it doesn't remove the entire need for browser helper applications
(after all, people still want to embed videos, etc., in web pages), it
does make the desktop experience much more consistent. Think things that
you can't (or shouldn't) embed into a web page, such as PDFs. If I click
a link to a PDF, I don't want it to save it permanently on my desktop
and then open in Evince. I don't want it to embed into my web browser. I
just want to see the PDF in the same way I'd see any other PDF, then
think about where I want to save it (if at all) later.

Yes, there are some problems with some web servers. Amazon, for example,
don't handle HEAD requests at all, so there's no way for us to get info
about resources other than by GETting them. This can be automatically
handled in GNOME-VFS, just by disconnecting after the response headers
have been sent.

Also is the fact that two connections need to be built up. One by the
invoking app for the file info request, and one by the invoked app for
the content request. This can be alleviated by moving the existing HTTP
pooling stuff into the GNOME-VFS daemon, which apparently is as easy as
editing a configuration file. This way, both a HEAD and a following GET
exist in the same persistent HTTP connection. Yay!

So, if you read this far, you are obviously very bored or very
interested. Please let me know what you think.

Thanks!

♥ GNOME
-- 
Alex Jones <alex weej com>