Re: Adding API for editing GnomeVFSVolume's

[Alexander Larsson <alexl redhat com>]

On Tue, 2005-09-13 at 07:58 -0600, Trevor Davenport wrote:
> >On 9/13/05, Alexander Larsson <alexl redhat com> wrote:
> > These all look likes function to edit parts of a uri only when its in a
> > specific place. Thats a very non-orthogonal API. We already have
> > functions to set the various parts of a uri, so all thats needed is a
> > way to change the uri of a connected server.
>  
> That's what I had in mind.  I felt it was easiest ( possible safest?)
> to use those functions to modify the uri of connected servers.  We
> can't have much of an api to edit anything other then connected
> servers and connected servers seem to really exist as just a uri
> pointing to the location.

I don't understand this. The code you showed had things like
gnome_vfs_volume_set_host_port(). These are really unnecessary, as long
as you can get/set the uri of the volume.

> > A GnomeVFSVolume is actually a distributed object that exists in all
> > clients of the volume manager, so just changing it in the memory of one
> > client doesn't work at all. Furthermore, there are locking and thread
> > issues in the daemon that make this even more complicated.
> 
> Could you please expand on this a bit more.  I figured there would be
> issues with just chaning it in memory.  Do we have to wait to change
> it until there are no lock? or can we only change it for opened
> connections?  Or tell me where the source is for this part so I can
> read over it.  There doesn't really seem to be any docs about this
> portion of gnome-vfs so I just went with what I could see looking at
> the source as a starting point.

The real GnomeVFSVolumeManager runs in the gnome-vfs daemon, and
GnomeVFSVolumeManager objects in actual gnome-vfs apps are just copies
of the daemon objects that are sent over from the daemon. You can't just
change your local copy of the volume and expect the daemon copy and all
other copies to change.

GnomeVFSVolumeManager and all the volumes/drives in it must be
threadsafe, because its used by things like the computer: gnome-vfs
method, and gnome-vfs methods are run in threads. The way the locking of
this is handled at the moment is dependent on the volumes not changing,
so if you change that you have to totally redesign the locking scheme.

> > Also, any API for this can't be named just gnome_vfs_volume_foo, because
> > that seems like it would work on any volume, when in fact it only works
> > for connected servers.
> 
> Where this api is really just to edit connected_servers I didn't
> really think it should be name gnome_vfs_volume but I didn't like
> gnome_vfs_connected_server because it is getting on the long side
> (though I have no problem with something like that if that would be
> preferred).

Yeah, naming can be hard. I prefer long names over misleading names, but
its possible there are good shorter names too.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a sword-wielding Amish vampire hunter with nothing left to lose. She's a 
sharp-shooting red-headed socialite with only herself to blame. They fight 
crime!