Re: Integration of gmc and nautilus desktop directories.

["Colm Smyth [RU-Ireland]" <Colm Smyth Sun COM>]

If someone is interested in developing a server for mount notification,
it would be amazing to have a one-stop-shop API for notifications about:

a) local mounts
b) removable media (floppy, cd-rom, zip, jaz)
c) shares on the LAN

b) is important because for example Linux and Solaris have very different
ways of handling removable media; we need to abstract these mechanisms
in Nautilus. c) is important because a LAN of workstations could have a
"network neighbourhood" feel if there was a way to find out about shares
on machines in the LAN.

The end-result of having a common notification API for mounts and shares
is you get an entry point for all storage mechanisms for a server.

It might be worth considering GConf as a mechanism for this notification
because:
- it provides an API for getting data
- it supports notification
- it allows information about a 'store' (e.g. a filesystem, a directory tree,
  a device, a WebDAV server) to be augmented with other properties or keys

I would actually suggest using GCOnf as an implementation technology and
layering a simple API on top of GConf (for replace-ability and ease of
programming).

My personal belief is that this "storage" API would ultimately also include
notification about changes in the filesystem, perhaps based around the
'fam' server.

Thoughts? ;)

Colm.

>Delivered-To: gnome-private-members gnome org
>Delivered-To: gnome-hackers gnome org
>From: "Gene Ragan" <gzr eazel com>
>To: <gnome-hackers gnome org>
>Subject: Re: Integration of gmc and nautilus desktop directories.
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
>X-BeenThere: gnome-hackers gnome org
>X-Loop: gnome-hackers gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: <gnome-hackers.gnome.org>
>X-BeenThere: gnome-private-members gnome org
>X-Loop: gnome-private-members gnome org
>
>> well, it depends on how one is mounting the partition.
>>
>> if i mount it from a shell, i care very little probably when it shows up
>> on my desktop.
>In all due respect, you are not the average user that I hope that an
>accessible and
>useable desktop linux environent will appeal to.  If a user has a desktop,
>it
>is only logical that mounted volumes should appear on it regardless of the
>method the mount occurs.
>
>(in practice, i find it more annoying that it pops up a
>> dialog saying "searching for trash folders" every time i mount it, and
>> then doesn't let me unmount for 30s+ while it is doing this search).
>>
>Red herring.
>
>> if i right click on the desktop then mount from there, the fm knows
>> something should be mounted soon, so it can start checking for the newly
>> mounted partition.
>>
>
>The real issue is how we should respond to the automounter, not to mount
>invocations from the terminal
>or desktop context click.  The suggested 5-10 second update delay in this
>instance is flawed.
>
>Gene
>
>
>
>_______________________________________________
>gnome-hackers mailing list
>gnome-hackers gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-hackers
>
>


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers