Re: Volume handling proposal

[Alexander Larsson <alexl redhat com>]

On Wed, 2003-09-17 at 12:20, Ken Deeter wrote:
> Sorry I rearranged your email a bit to make what I want to say flow better.
> 
> > Still not sure what roots make sense in the file selector. Do we want
> > to allow mounting of e.g. floppies from the file selector?
> >
> 
> Small technical question.. does this mean the gtk fileselector will
> depend on the gnome-vfs? or will some gnome lib extend the gtk file selector?

The new gtk+ fileselector has the filesystem backend abstracted out, so
we will be able to plug gnome-vfs into it. This will be done by some
gnome library, so its supposed to "just work". All the details aren't
hashed out yet, but the discussion is going on in the gtk development
list, and the code is in cvs.

> As there is so much effort duplicated between KDE and gnome in terms of
> virtual file systems, this is where we REALLY NEED a freedesktop.org
> standard. I think since gnome did just make a major release, we really
> should think about starting something correctly so that unix systems in general
> can have a sane 'volume management' system that KDE, gnome, and whatever other
> desktop can provide different interfaces to.
>
> Since there is a HAL daemon started already, it seems only natural to
> try to start up a parallel project that handles exactly what this thread
> is here to discuss. I think its fairly obvious that basic VFS stuff is
> not desktop interface specific, nor should it be. I would hate to see gnome and
> kde especially just go down the same diverging paths they have been, and
> have half-baked vfs solutions in both, when we could have a good vfs
> solution common to both.

Well, this mail is mostly about the user interface, exactly what VFS is
used underneath it isn't really the important part, although the
implementation notes part does use gnome-vfs. If we can agree on the
behaviour we want for the desktop we can implement that over any VFS
implementation we want.

I'm on the freedesktop project, and there is discussions about a shared
VFS layer. But I think you severely misjudge the difficulty in doing
that. Most other freedesktop standards are about file-formats. Here we
have to share API/ABI, code freeze dates, codebase etc. For the near
future, gnome-vfs is what we have, so thats what the initial
implementation will use.

> I realize the architecture is quite different, (kio versus gnome-vfs
> methods) but the required functionality is so straightforward and
> similar that a well-designed, well-performing solution should be easy to
> adapt to both.
> 
> It seems silly that we can agree how to do thumbnails, window managers
> and not VFS, considering that both the concept window managers and
> images came way after filesystems did.

You wish! We can't even agree about filesystem semantics between
different gnome-vfs modules.
 
> > What about printers etc? "Computer" is essentially only "filesystems
> > accessible on the computer" right now, but it *could* be extended to
> > be more like a "hardware connected to the computer", although that
> > makes network filesystems not fit in there as good, and introducing
> > non-files in the filesystem is dangerous as noted above.
> > 
> 
> This starts to get into the HAL kind of idea, and I really really hope
> that gnome developers will have just a little foresight and try to do
> something that is desktop agnostic.

I'm discussing the gnome desktop user model. Of course we should share
as much underlying implementation as is possible/make sense, but we
shouldn't let the plumbing control the user experience. Thats why we
start with designing the ui.

> > First concept is a virtual location called "Computer", which is a
> > "root" of all the volumes in the system, much like "My Computer" in
> > WinXP and "Computer" in MacOSX. 
> >
> 
> This should be a choice in interface design, not in the underlying system.
> Organization access to system services is an interface issue, providing
> these services has nothing to do with the desktop.

Yes. That is why I wrote this mail. To choose the interface design.

> > Second one is the MacOS X concept of connected network
> > volumes. You select "Connect to server" in a menu, and then using
> > either manual typing or a browser for some types of servers you select
> > a server and directory. This location is then saved between sessions
> > and easily accessible. This allows you to quickly access commonly used
> > shares, and is also a way to introduce a way to intelligently handle
> > non-discoverable network shares. At the very least you only have to
> > figure out/get told that strange ssh: uri once.
> > 
> 
> Windows also has the "Map network drive" which is essentially the same thing.

Not really, I consider "Mapped drives" to be more like local mounts in
unix. They are introduced into the filesystem, and are limited to smb
shared. Windows XP has instead something called "My Network Places",
where you can "Add network place". Here you can add whatever type of
share you want, even ftp sites. This is more like what i'm proposing,
although in my proposal it is a bit more visible.

> Even smbfs and nfs mounts on linux are sort of the same thing (just not
> user level operations, but that has to do with permissions more than anything else)
> 
> My point that it is nothing specific to OS X, and especially not specifc
> to OS X's interface. All OS's (at least listed here) provide some kind
> of similar service, each just gives u a diff interface. If you start talking about
> the ('net') commands in WinNT/2000/xp then you get very similar to 'mount'

I don't claim that the concept is unique to OS X, that would be stupid
and irrelevant. But the implementation that is closest to what I
proposed is in OS X, so its a good thing to refer to.

> > Third one is the "Network" location. Ideally this contains all the
> > servers in the current windows workgroup, all zeroconf webdav servers
> > on the local net and all other discoverable network shares. It also
> > contains a "Windows Network" icon linking to smb://. Windows XP does
> > this a little bit different, they list every share on every server in
> > the workgroup as "<share> on <server>". There might be quite a lot of
> > these though, and querying for them requires you contact each
> > computer, so this is probably not a good idea.
> 
> Again, this is just a variation on the interface, the presentation
> manner, and makes no specific requirement on the system that supports it
> underneath, except to be able to say "give me a list of shares"

Yes. So it is makes perfect sense in a mail discussing the interface.

> > Since we want to share volumes with apps using the new file selector
> > its clear that the code can't be all in Nautilus. This means that the
> > code in NautilusVolumeManager has to be split out from Nautilus
> > (probably rewritten, it stinks) and put in some common library, such
> > as gnome-vfs or libgnome. We should probably do the actual probing etc
> > in a separate process so that not all apps have to do this. This
> > matches well with the current plans for a gnome-vfs daemon. So
> > gnome-vfs might be a good place for this. It also makes sense for
> > gnome-vfs to handle the "connect to server" backend code.
> 
> > Since we need to handle the list of volumes in various ways in
> > different places it makes sense to make the volume api a real api (not
> > some vfs module).
> 
> Exactly! why not libvfs? forget anything about gnome, nothing we would
> put in this lib would be gnome-specific. We just need to make sure that
> it implements all the features that we would want it to to make the
> interface we wish possible. We could probably steal a whole bunch of
> code from kde too.

The API i talk about here isn't really vfs as such. Its just code that
monitors the mounts in the system, using getmntents() and monitoring
mtab etc. It makes sense to put in gnome-vfs to avoid
yet-another-library and yet-another-daemon.

However, sharing code between the desktops is a complicated thing. To
accomplish this in a sane way we would have to have a common minimal
component system, a shared lowlevel runtime (or we could just duplicate
every datatype like dbus does), etc. Try reading some of the flames on
xdg-list about glib usage and you'll see why this is really hard.

> [Gnome]         [Kde]               [Desktop x]
>     |             |                    |
>   [gtk]       [qt, kdelibs, kio]    [whatever]
>     |             |                    |
> [libvfs and vfsd, hal daemon, image thumbnails, vfolder, iconv]
> 
> I really think this is the kind of situation we need to be going for. If
> we can add stuff to the bottom layer that is appropriate, then we really
> should go for it.

The problem is that to develop stuff you want to use a stack of software
that makes devlopment easier, and in your model this stack is in the
[gtk] and [qt..] parts. This means the lower level software is really
hard to write and integrates poorly with the development stack that
applications then use.

The reason this works for i.e. image thumbnails and vfolders is because
the standard is only about the fileformats, and the code is implemented
by each desktop in a way that fits their platform. iconv works because
its a pretty simple API, which don't need much support or integration
from the runtime. The HAL works because dbus separates the different
stacks, and each stack has its own dbus integration code, and dbus
itself painstakenly duplicates a lot of functionallity to avoid
depending on either stack.

> > How do we handle burn:? I really like the way where its sort of
> > invisible in the UI until you insert a blank cd and magicdev detects
> > it. This doesn't work without magicdev, but maybe clicking on the CD
> > in computer could try to detect a blank cd and go to burn:. Of course,
> > this gives problems with rewriting CD-RWs and burning .iso images, so
> > i guess this has to be visible some other way in the UI too. Maybe
> > right click on the cd device icon and select "burn to cd"?
> > 
> 
> The problem with this one is that it doesn't really fit the semantics
> of a filesystem as the other gnome-vfs type modules do. burn:// is
> really an application, not a volume. Although it is a nifty way to 
> re-use nautilus components, I would argue that the best thing to do is
> to think of it as a separate application altogether.. just one that has a very
> 'familiar' interface. Its defining characteristic is that it has operations
> other than what a FS traditionally has, namely, 'burn' and 'blank cd'.

How is it an application? Its just some storage space for files? Thats
like saying a CD is an application because it has an 'eject' operation.

> it would be the same if we had printer:// or something, we would need buttons
> probably for 'delete job' 'change prioriy' etc. etc... I'm all for making
> these things heavily re-use nautilus components, but it may be much to try
> to force them into a filesystem concept.

I agree with this, i don't think printers should be exposed like this,
but some people do.

> I'm sorry this kinda sounds like a rant (and sorry Alex, its not really
> aimed at you.. you just brought it up, and its been bothering me for a
> while), but the main point is, If we're gonna have to write all this
> from pretty much scratch anyways (as there arent really any equivalents
> available on linux, unless u count lufs), there's really no point making
> it GNOME-specific. I think we owe it to everyone who volunteers their
> hours to free software projects to differentiate what we want to do with
> our interface, and what we need to implement at the system level. Doing
> it correctly is not that much more work, and the benefits are
> tremendous.

I really think you misread my email. It is not about reimplementing
anything. Its about designing a coherent user interface that ties
together all the different parts we already have in Gnome in a way that
users can understand.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a witless vegetarian farmboy haunted by an iconic dead American 
confidante She's an orphaned psychic hooker with a knack for trouble. They 
fight crime!