Re: getting the list of all gnome-vfs modules

[Michael Meeks <michael ximian com>]

Hi Christophe,

On Wed, 2002-08-21 at 13:23, Christophe Fergeau wrote:
> > 	So you want to know that inside gnome-vfs ? if so it should be easy to
> > add a method that groks that information. How is this data exposed to
> > the real world though ? can we API compatibly export the fact that we
> > handle all types easily ?
> 
> Actually, I looked more deeply into that yesterday evening, and it is
>  not that difficult to get the list of available modules by adding one
>  new method to gnome-vfs-configuration.c (iirc api additions aren't abi
>  incompatible changes ?) and a new #define to one .h file (that's
>  probably also ok with respect to abi compatibility).

	API additions are fine in the development branch (HEAD); unfortunately
it's not at all clear to me if the development branch will ever see the
light of day; it _looks_ to me as if no work is being done on HEAD -
apart from merging fixes from stable, but there is a considerable
element of "work in progress" going on in there - that has to be
finished before we can release it at 2.2, and it's not clear if this is
going to get done.

	Thus the question of where to put your changes - is rather a difficult
one.

	I believe what you want to do is to find some private ( not installed )
header, and add the method prototype to that; so it's not adding public
API. And treat this feature as a bug fix to gnome-vfs-2.0 - since it
really is a bug that we can't specify "uses all vfs schemes" - really
broken ;-)

> Then it looks like it's possible to handle the "I handle all types"
>  without further non internal changes

	Yes I think it has to be.

>  Indeed, the information contained in
>  .application files is internally stored in a non public struct
>  Application (defined in gnome-vfs-application-registry.c) to which I
>  can add a new boolean.

	I'd switch the existing gboolean to a guint user_owned : 1; and add
another bit-field for your thing; it might also be worthwhile moving the
expect_uris into the 'ints' block, so we don't waste more space
mid-structure with pointer alignment requirements - or maybe I'm
paranoid.

>  When an app needs the information about a given
>  app, this internal structure is copied to a GnomeVFSMimeApplication
>  which has a list of string corresponding to the supported uri schemes.
>  So I just have to add the list of all gnome-vfs supported uri strings
>  to that list when necessary. 

	Sounds fine; for now.

> The only limitation will be that an app won't know that the app it's
>  asking info about had the all_gnome_vfs_schemes_supported field set,
>  which is not a problem imo. Anyway GnomeVFSMimeApplication has 8 bytes
>  of padding if we need to add a field for that.

	I think we need to treat that padding like gold dust ;-)

> Another thing that I saw yesterday when I started hacking on that : I
>  was wondering if methods like vfolder-desktop, preferences, ... should
>  be filtered or not. 

	Hmm;

> Also, I was wondering if it was necessary to let apps specify which
>  gnomevfs methods must be defined so that they can do something
>  sensible with an uri (for example, some apps may only need
>  open/read/close, some other open_dir/read_dir/close_dir, another app
>  may need open/read/close but also write and so on). But maybe we can
>  rely on gnome-vfs modules to implement enough methods and let apps
>  handle themselves missing methods.

	Sounds quite complicated - ultimately if it's has complex requirements
it gets to startup and fail - telling the user that it needs to open
R/W/Seekable but it can't because the thing's RO/linear.
The problem is that adding this sort of complex constraint in gnome-vfs
will only lead to more complexity - different formats need different
constraints etc. ;-) [ some are not mime-sniffable ] etc. etc.

> Thanks for your answer, i was getting desperate of gettint any answer to my mails :)

	No problem; keep up the good work - looking forward to a patch
arriving.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot