Default browser setting

[Rodney Dawes]

On Fri, 2003-07-25 at 17:14, Lars Hallberg wrote:
> Christophe Fergeau wrote:
> 
> >I consider the "default browser" as being "the app which I use to open html files". That means that if I double click on a local html file, I want it to open in my "default browser". On the contrary, if I double click on a http://domain.com/toto.ps, I don't want to open it in a browser to be asked which app should be used to open it, it's better to directly launch an app which can handle this uri if there is one available.
> >  
> >
> 
> If the app lanching the uri don't suport http this might be hard. It's 
> not for sure your prefared ps viewer suports http ether. So lanching a 
> default browser might be the best way.

That's why there is a flag to specify whether or not the app can handle
URIs. This is the case with gnome-vfs anyway. The real problem here is
one with the mime database, and lack of vfs support throughout the
libraries, to just provide transparent support. You can workaround this
like mozilla does, by downloading the file to /tmp/ and then opening it
from there.

> Idealy, that browser do (at least given the right command line togle) 
> automaticly lanch the right wiever for the file (using the mimetype 
> database), and don't open a window for itself unless it's viewing the 
> file nativly (and quit when it's job is done otherwise).

If you launch a browser only to have it launch what is configured in the
mime database, instead of doing it directly, you are doing nothing but
adding a point of failure. If the browser can't handle the mime type, it
is most likely going to pop up a dialog to ask if you want to save the
file or open it in an application.

> This problem may have become lesser with the existans of vfs librarys, 
> but not all apps want to link those librarys.

Broken apps aren't a good excuse for broken implementations. :)
In Mac OS or Windows, you don't really have much choice. You have to
write a bunch of extra code to make it not use the filesystem stuff
that's provided by the higher-level libraries. It's just not worth it
to not have that support. And again, the download to /tmp, and open a
local file, workaround, is still an option. One that we should probably
be doing for now.

> BTW, I saw a vfs working att the filesystem level, so opening 
> http://domain.com/toto.ps would mean opening a regular file att a given 
> mountpoint, for example /uri/http/domain.com/toto.ps - As it to userland 
> is a regular file, it can be feed directly to any viewer!!!
> 
> Thats cool, an given that http headers can be preserved as fs metadata 
> (I'm prety clules at that extended metadata stuff), I think it's the 
> prefered way to impliment a vfs!
> 
> If it's possably. I think that is an asperant for standardisation, how 
> to map uri to path, how to map different protocolls metadata to fs 
> metadata, how to map logininfo to path (that might not be so secure, 
> better idés?), etc.

A URI is a mapping of protocol, username, password, host, path, and
filename. I don't see why we need to re-implement it to work with old
applications that are probably going to get replaced at some point
anyway. There are many ways to implement a VFS layer for the system.
I don't see what doing it at the kernel level with modules that may
be hackish, or introduce security issues, or may never actually go into
the upstream kernel, gains us. We already have VFS implementations for
pretty much every desktop platform now. We should use them, fix them,
and make them worthwhile for people to use, rather than finding more
ways to avoid working on them.

> Not desktop specifik, but realy usfull for a desktop system!

HURD isn't desktop specific either, but I'd rather not wait around for
another 30 years for a nice microkernel with vfs built in.

-- dobey