Re: Plans for gnome-vfs replacement
Hi! Sorry for replying to ancient mail. > For example, we could be to use "//.network/" as a prefix for the vfs > filename namespace. A smb share might then be accessed as > "//.network/smb/computer:share/dir/file.txt", or a ftp share as > "//.network/ftp/[EMAIL PROTECTED]/dir/file.txt". With a setup like > "//.network/$method/$mount_object/" it would be quite easy to find the > process handling the mount. Just ask for a dbus named object like > "org.glib.gvsf.smb.computer:share". It is also very easy to detect > local filenames and short-circuit to in-process i/o. You don't want to use notation above -- because someone will try ls //.network, or worse ls //.network/ftp . Midnight commander grew solution for this (similar to your /:ftp:...)... it is /#ftp:[EMAIL PROTECTED]/foo/bar . It can nicely handle tar (and similar) archives, like /#ftp:[EMAIL PROTECTED]/foo/bar.tar#utar/x.c . avfs used that notation at some point too (still does?). Please consider using it, too. Pavel -- Thanks for all the (sleeping) penguins. ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On 29/09/06 09:16, Alexander Larsson wrote: > On Wed, 2006-09-27 at 23:52 +0200, Mourad De Clerck wrote: >> I was just wondering if it would still be possible to refer to a file >> through chained URIs (or IRIs, or whatever new alternative system you're >> proposing) >> in that case, how do you pass parameters to the chained parts, like for >> instance a zip password for the last part of the chain? Serializing it >> in the URI/IRI itself (...tory/file.txt?password=12345) might be a bit >> ugly...? > > I dunno. This never quite worked in gnome-vfs, and the KIO guys said it > was nothing but problems for them. I'm not sure its really all that > important. Well even relatively basic things like accessing a zip file on a samba share would need it. Unless you expect users to copy the file to their desktops first? Or do you mean that users would be able to browse them, but there would simply be no way to actually refer to them (state is hidden) - so no referring to those nested-mount-files in .desktop or the mentioned "shortcuts"? >> imap://[EMAIL >> PROTECTED]:143/fetch%3EUID%3E.INBOX%3E666#mime:///attached_file.zip#zip:///directory/file.txt >> > Of course, the above example URI is a prime example of all that is wrong > with using general URIs for a vfs. Any well-defined filesystem semantics > that will also support an imap backend is gonna suck raw eggs for actual > users of normal files. what's so special about IMAP? Its ACLs are a bit weird, but from what you described I understood ACL-type metadata to be backend-dependant in any case. Operations like you describe (read-entire-file, copy-file, ...) would not be a bad match for imap either (posix-style would be harder). In any case, it was just meant to be a pathological example. -- Mourad ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Fri, 2006-09-29 at 17:52 +0200, Magnus Bergman wrote: > > > You're only mentioning the low-level stream parts here, but is > > > there any previous work of a filesystem/virtual folder API apart > > > from POSIX which could be used as a comparision? > > > > > > Do you know what win32, OS/X, Java, .NET, etc provide in this area? > > > > I like the java.io.File class which does the pathname abstraction. > > Win32 has something called "Shell extensions" which are similar to > > the whole VFS layer. Other than that there is not a lot of previous > > art. > > I have a few years of experience with a commercial VFS implementation > from Verity [1]. I won't go into details (it is actually way too > complicated) but it kind of works like this: > > Backends can provide one of a few APIs. The one I find most usefull is > the streaming API. Streams are not necessarily identified by > filenames, any type of string can be used (and in some way it gets > mapped to a backend which knows how to interpret it). Then you open a > stream using this you specify which metadata you are interested in. > There are some standard stuff you can add to a bitfield (author, > filename, mimetype etc), but you can also specify custom fields which > are often specific to the backend. Everything is then transfered as > packages, containing either one metadata item or a chunk of the > contents. You can request seeks of the stream but they might be denied, > delayed or inexact (and the only way to tell is by the offset in the > coming chunks). It can also have backends which take input streams > (which can be used to access files in an archive or to convert files on > the fly). (I guess this is also kind of similar to GStreamer, but less > advenced since GStreamer can do a lot more like can relink the > stream dynamically.) > > The good thing is that it's very flexible. Things are usually done in > the most efficient way. But the user of the API must take on a lot of > the responsibility so it's all but a beautiful thing. Interesting. It seems pretty similar to what I'm thinking, but a bit more taxing on the API user and a bit more lenient for the backend implementation (which sometimes can lead to more efficient implementations). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an ungodly guitar-strumming rock star who knows the secret of the alien invasion. She's a disco-crazy impetuous college professor with the power to bend men's minds. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
> > You're only mentioning the low-level stream parts here, but is > > there any previous work of a filesystem/virtual folder API apart > > from POSIX which could be used as a comparision? > > > > Do you know what win32, OS/X, Java, .NET, etc provide in this area? > > I like the java.io.File class which does the pathname abstraction. > Win32 has something called "Shell extensions" which are similar to > the whole VFS layer. Other than that there is not a lot of previous > art. I have a few years of experience with a commercial VFS implementation from Verity [1]. I won't go into details (it is actually way too complicated) but it kind of works like this: Backends can provide one of a few APIs. The one I find most usefull is the streaming API. Streams are not necessarily identified by filenames, any type of string can be used (and in some way it gets mapped to a backend which knows how to interpret it). Then you open a stream using this you specify which metadata you are interested in. There are some standard stuff you can add to a bitfield (author, filename, mimetype etc), but you can also specify custom fields which are often specific to the backend. Everything is then transfered as packages, containing either one metadata item or a chunk of the contents. You can request seeks of the stream but they might be denied, delayed or inexact (and the only way to tell is by the offset in the coming chunks). It can also have backends which take input streams (which can be used to access files in an archive or to convert files on the fly). (I guess this is also kind of similar to GStreamer, but less advenced since GStreamer can do a lot more like can relink the stream dynamically.) The good thing is that it's very flexible. Things are usually done in the most efficient way. But the user of the API must take on a lot of the responsibility so it's all but a beautiful thing. [1] http://www.verity.com/ ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-27 at 23:52 +0200, Mourad De Clerck wrote: > I was just wondering if it would still be possible to refer to a file > through chained URIs (or IRIs, or whatever new alternative system you're > proposing) > > so would something like the following still be possible (in theory, I > know there's no imap: or mime: vfs modules): > > imap://[EMAIL > PROTECTED]:143/fetch%3EUID%3E.INBOX%3E666#mime:///attached_file.zip#zip:///directory/file.txt > > in that case, how do you pass parameters to the chained parts, like for > instance a zip password for the last part of the chain? Serializing it > in the URI/IRI itself (...tory/file.txt?password=12345) might be a bit > ugly...? I dunno. This never quite worked in gnome-vfs, and the KIO guys said it was nothing but problems for them. I'm not sure its really all that important. Of course, the above example URI is a prime example of all that is wrong with using general URIs for a vfs. Any well-defined filesystem semantics that will also support an imap backend is gonna suck raw eggs for actual users of normal files. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a superhumanly strong one-eyed senator on the hunt for the last specimen of a great and near-mythical creature. She's a foxy renegade mechanic with only herself to blame. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
I was just wondering if it would still be possible to refer to a file through chained URIs (or IRIs, or whatever new alternative system you're proposing) so would something like the following still be possible (in theory, I know there's no imap: or mime: vfs modules): imap://[EMAIL PROTECTED]:143/fetch%3EUID%3E.INBOX%3E666#mime:///attached_file.zip#zip:///directory/file.txt in that case, how do you pass parameters to the chained parts, like for instance a zip password for the last part of the chain? Serializing it in the URI/IRI itself (...tory/file.txt?password=12345) might be a bit ugly...? Anyway, glad to hear you're tackling it. -- Mourad ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-27 at 09:06 +0200, Alexander Larsson wrote: > On Tue, 2006-09-26 at 19:01 -0400, Hans Petter Jansson wrote: > > On Mon, 2006-09-25 at 13:14 +0200, Alexander Larsson wrote: > > > The way I had planned this was to always use true async i/o when talking > > > to the vfs daemon via sockets (easy), but implement local async i/o > > > using threads. If glib threads are not initialized we'd just fall back > > > to doing blocking "async" calls. > > You could use AIO on Linux and the equivalent on BSD, if you think it's > > worth the effort. Flow will have an AIO-based implementation eventually. > Unfortuantely the linux support isn't good enough. I talked to some > kernel people, and it would seem this is still pretty much the status > wrt posix aio: > http://lwn.net/Articles/148755/ > > In particular, we would need fixes for at least restrictions 1, 5 and 7. I think restriction 1 is the most serious for us, but we can work around it if we: - Always manage our own FD life cycles (i.e. no user-provided FDs, which is a good idea for portability too). - Copy/move data into aligned buffers. I don't consider 5 and 7 blockers. We can work around 5 with no-op priorities (much as we do for threads) and 7 by keeping the state of canceled operations around until the operation completes. Then this can be fixed under the hood when the kernel gets its shit together. Of course, just using threads is a lot easier. The "generic Unix-like" implementation I wrote for Flow uses threads for file I/O. The AIO implementation will be a Linux-specific bonus, for when the more important stuff is done. -- Hans Petter "...you cut a piece, and as you're taking it off of the fork the main piece of the filet may be floating up out of the plate, but you stab it with your fork and put it back down in, and if you do it carefully, the surface tension of the gravy will keep it in place." - Russell Schweickart ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-26 at 19:01 -0400, Hans Petter Jansson wrote: > On Mon, 2006-09-25 at 13:14 +0200, Alexander Larsson wrote: > > > > The way I had planned this was to always use true async i/o when talking > > to the vfs daemon via sockets (easy), but implement local async i/o > > using threads. If glib threads are not initialized we'd just fall back > > to doing blocking "async" calls. > > You could use AIO on Linux and the equivalent on BSD, if you think it's > worth the effort. Flow will have an AIO-based implementation eventually. Unfortuantely the linux support isn't good enough. I talked to some kernel people, and it would seem this is still pretty much the status wrt posix aio: http://lwn.net/Articles/148755/ In particular, we would need fixes for at least restrictions 1, 5 and 7. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a short-sighted shark-wrestling vagrant from the 'hood. She's a cosmopolitan nymphomaniac magician's assistant with the soul of a mighty warrior. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 13:14 +0200, Alexander Larsson wrote: > On Mon, 2006-09-25 at 11:40 +0200, Tim Janik wrote: > > hm, in your initial proposal, you said that apps don't currently have > > control > > over whether they want to use/care about threading or not. so, are you > > planning for a way to use the GVFS API without threading under the hood? > > then, emulation of the above asny calls would be implemented in terms of > > IO handlers attached to the provided GMainContext *context? > Its an unfortunate fact of life that unix doesn't support asynchronous > I/O for local files. I.E. a select on a local file *always* returns that > it is readable, but it might still block when you call read() while > reading the data from the disk. So, unless the OS has a good > implementation of posix async i/o (which e.g. Linux doesn't) the only > way we can get true async local file i/o is using threads. > > The way I had planned this was to always use true async i/o when talking > to the vfs daemon via sockets (easy), but implement local async i/o > using threads. If glib threads are not initialized we'd just fall back > to doing blocking "async" calls. You could use AIO on Linux and the equivalent on BSD, if you think it's worth the effort. Flow will have an AIO-based implementation eventually. -- Hans Petter "...you cut a piece, and as you're taking it off of the fork the main piece of the filet may be floating up out of the plate, but you stab it with your fork and put it back down in, and if you do it carefully, the surface tension of the gravy will keep it in place." - Russell Schweickart ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 10:29 -0400, Dan Winship wrote: > Alexander Larsson wrote: > > On Sun, 2006-09-24 at 22:49 -0400, Dan Winship wrote: > >> There might also be problems with IRI-based gvfs and URI-based gnome-vfs > >> wanting to using different URLs to refer to the same file? > > > > Thats already possible in thousands of ways. You can use different case > > for hex escape, escape various sets of chars, add "/./" to the path, > > etc, etc. Non-canonicalized URIs are very much not unique. > > Right, sorry, I meant I was wondering if there were cases where the > *canonicalized* forms are different in an incompatible/incomprehensible > way. Like if gvfs thought "ftp://ftp.gnome.org/dir/a%20%E5%E4%F6.txt"; > pointed to a file with an iso-8859-1-encoded name, and gnome-vfs thought > it pointed to a file with a UTF-8-encoded name, and so you'd either get > a different file or a file not found error when you traded the URI > between gvfs and gnome-vfs. (That example is probably completely bogus, > which is why I didn't give an example in my original mail, but hopefully > you get the idea.) All URIs are valid IRIs. All IRIs are either a valid URI refering to the same file, or an invalid URI (one that contains chars that are not allowed). The only difference between the two formats is that if a URI has escaped chars that would unescape to valid utf8, it would be a valid IRI if they were unescaped. We never actually care about the encoding of the filename for any uri operations other than displaying it. I.E. even if we know the ftp uses iso-8859-1 filename encodings we don't convert the a%20%E5%E4%F6.txt in your example to utf8, because that would result in the problem that you explain. The only thing IRIs do is *if* a URI is valid UTF8 we can display the unicode chars unescaped. If we think the ftp site uses iso-8859-1, but one file accidentally use utf8, then we will display a nice name for that file, and that file only. As I said, this is not ideal, but it will at least never cause any compatibility issues, and its "future proof" in that most places are moving to utf8 (ietf/w3c recommends it for all new URI schemes). Also, the discussion above is only true for the absolute display names shown in the nautilus/file selector location bar. For the filenames displayed under each icon in a nautilus view we can correctly convert 8859-1 to utf8, because in these cases we keep the real filename around for when we do operations on the file. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a fast talking native American hairdresser with a winning smile and a way with the ladies. She's a hard-bitten bisexual barmaid from aristocratic European stock. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
Alexander Larsson wrote: > On Sun, 2006-09-24 at 22:49 -0400, Dan Winship wrote: >> There might also be problems with IRI-based gvfs and URI-based gnome-vfs >> wanting to using different URLs to refer to the same file? > > Thats already possible in thousands of ways. You can use different case > for hex escape, escape various sets of chars, add "/./" to the path, > etc, etc. Non-canonicalized URIs are very much not unique. Right, sorry, I meant I was wondering if there were cases where the *canonicalized* forms are different in an incompatible/incomprehensible way. Like if gvfs thought "ftp://ftp.gnome.org/dir/a%20%E5%E4%F6.txt"; pointed to a file with an iso-8859-1-encoded name, and gnome-vfs thought it pointed to a file with a UTF-8-encoded name, and so you'd either get a different file or a file not found error when you traded the URI between gvfs and gnome-vfs. (That example is probably completely bogus, which is why I didn't give an example in my original mail, but hopefully you get the idea.) -- Dan ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 25 Sep 2006, Alexander Larsson wrote:
> On Mon, 2006-09-25 at 13:00 +0200, Tim Janik wrote:
>> On Mon, 25 Sep 2006, Alexander Larsson wrote:
>>
>>> On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
Hey Alex,
Great that you are planning to redesign the VFS.
> Here is my current GInputStream:
>
> struct _GInputStreamClass
> {
> GObjectClass parent_class;
Using GTypeInterfaceClass here would make it much more easy to let
library and application developers implement the GInputStream interface
in a for-their needs suitable way.
>>>
>>> I'm well aware of interfaces. In fact my initial version used an
>>> interface for this. However, there are other aspects of the equation
>>> that has to be taken into account to. For instance, using a base class
>>> means you can inherit functionallity from the baseclass. This makes it
>>> much easier to implement things, because we can do the fallback async
>>> wrapper in the base class, and it makes it much easier to do wrapping of
>>> streams.
>>
>> not taking side on the interface vs. object issue here. however note, that
>> you can provide default implementations for interfaces with GType, simply
>> by hooking up class function pointers in the class_init function passed
>> when registering the interface type, i.e. just like with object type
>> registration.
>
> How does this work in say a Java binding. There you can't specify that
> you implement an interface without having all the methods in the
> interface, and there is no way to chain up.
i really have no idea how the java gtk bindings work. but in any case,
a binding can't recognize if an object implements methods of an interface
itself or if the interface had default implementations already.
you're right that you'll get trouble implementing input/output streams
in java though, if it only supports chaining for object methods and not
interface methods (which GType explicitely supports).
> Furthermore, you might want to store some data in the parent object to
> handle the default implementation, and I'm not sure where you would do
> that in this case. g_object_set_data() seems a bit ugly.
g_object_set_data() is about the only thing you have available here.
the problem with object data and interfaces is really that your interface
has no way to hook into object construction or dispose, and you only get
finalize notification as an interface implementor by using g_object_set_data().
so if you start to keep significant state in an interface implementation,
you can try how far you get with g_object_set_data() but it's usually best
to move to an object at that point. (e.g. if you keep open sockets, it might
make sense to close them in dispose, and not only finalize).
so in that regard, C++ multiple inheritance is a win over GTypeInterface,
as it allows you to encapsulate implementation details better for interfaces,
by functioning beyond the need of per-object data in interfaces.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander LarssonRed Hat, Inc
> [EMAIL PROTECTED][EMAIL PROTECTED]
---
ciaoTJ
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 02:57 +0100, matt wrote: > May a newbie Windows convert make a suggestion or two ? > > > 1) Could you please make it stop telling me I'm wrong ? > > For example :- > I'm trying to get to grips with monodevelop and I save some data out as > xml, with .txt extension. > I do this to make it easier to hand edit to insert specifically > malformed bogus test cases before re-loading it into my test application. > > Double clicking on the "myxmlfile.txt" results : > > Expected > Launch gedit and read in the file. > > Actual > It tries to tell me I'm wrong > > Ok so try to open it in gedit and gedit just wines about it's type ! > > Please tell me how to tell it easily that I *seriously* want it treated > as a text file or as a csv or as anything I tell it whenever I say so - > how dare it try to out guess me! By all means notify me in the > properties for the file, but otherwise please tell me how to make it do > as it's told ! Weird behaviour. Aside the fact that filename extension doesn't really dictate the file-type as much as it does verify it, it looks like the XML you're saving isn't plain text. As a result, it doesn't verify as text/plain (.txt). > 2) Could you get it to mount the file systems so that they are available > from the shell as well as the gui ? > Sorry, this is another Windows hangover, but is none the less incredibly > frustrating. GNOME-VFS doesn't "mount" anything. If you want something similar to a text-mode nautilus interactive shell, we could of course start talking about a hypothetical "gnomesh". :P -- Alex Jones <[EMAIL PROTECTED]> ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 13:00 +0200, Tim Janik wrote:
> On Mon, 25 Sep 2006, Alexander Larsson wrote:
>
> > On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
> >> On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
> >>
> >> Hey Alex,
> >>
> >> Great that you are planning to redesign the VFS.
> >>
> >>> Here is my current GInputStream:
> >>>
> >>> struct _GInputStreamClass
> >>> {
> >>> GObjectClass parent_class;
> >>
> >> Using GTypeInterfaceClass here would make it much more easy to let
> >> library and application developers implement the GInputStream interface
> >> in a for-their needs suitable way.
> >
> > I'm well aware of interfaces. In fact my initial version used an
> > interface for this. However, there are other aspects of the equation
> > that has to be taken into account to. For instance, using a base class
> > means you can inherit functionallity from the baseclass. This makes it
> > much easier to implement things, because we can do the fallback async
> > wrapper in the base class, and it makes it much easier to do wrapping of
> > streams.
>
> not taking side on the interface vs. object issue here. however note, that
> you can provide default implementations for interfaces with GType, simply
> by hooking up class function pointers in the class_init function passed
> when registering the interface type, i.e. just like with object type
> registration.
How does this work in say a Java binding. There you can't specify that
you implement an interface without having all the methods in the
interface, and there is no way to chain up.
Furthermore, you might want to store some data in the parent object to
handle the default implementation, and I'm not sure where you would do
that in this case. g_object_set_data() seems a bit ugly.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's a scrappy shark-wrestling boxer possessed of the uncanny powers of an
insect. She's a strong-willed tomboy politician from Mars. They fight crime!
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 12:47 +0200, Tim Janik wrote:
> On Mon, 25 Sep 2006, Alexander Larsson wrote:
> > Also, In your example above the extra structure isn't needed. One would
> > just use different destroy notifiers for the two streams.
>
> hm, different? you mean you'd encode whether it's stream1 or stream2 in
> the destroy notifier callback implementation?
> well, that breaks as soon as the user has a non-fixed number:
> struct UserObject {
>guint n_streams;
>GOutputStream **streams;
> };
>
> as an anecdotal side note, one case where i originally went for just
> having a single data argument in the destroy notifier, and later had
> to extend the callback signature to also cover the original object due
> to user requests was GWeakNotify.
> in your case, i think it's pretty forseeable that passing the object
> handle along with the destroy notifier _can_ be useful and is easy to
> implement on the caller side. if it's lacking, it's really tedious to
> substitute on the user side though, so it'd be best to go with a signature
> like that of GWeakNotify from the start.
The main thing I have against this is that it litters the namespace with
lots of type declarations for various types of seldomly used destroy
notifiers.
Anyway, this is clearly not the most important issue atm. :)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's an otherworldly Amish rock star with no name. She's a cynical insomniac
college professor trying to make a difference in a man's world. They fight
crime!
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 11:40 +0200, Tim Janik wrote: > hm, in your initial proposal, you said that apps don't currently have control > over whether they want to use/care about threading or not. so, are you > planning for a way to use the GVFS API without threading under the hood? > then, emulation of the above asny calls would be implemented in terms of > IO handlers attached to the provided GMainContext *context? Its an unfortunate fact of life that unix doesn't support asynchronous I/O for local files. I.E. a select on a local file *always* returns that it is readable, but it might still block when you call read() while reading the data from the disk. So, unless the OS has a good implementation of posix async i/o (which e.g. Linux doesn't) the only way we can get true async local file i/o is using threads. The way I had planned this was to always use true async i/o when talking to the vfs daemon via sockets (easy), but implement local async i/o using threads. If glib threads are not initialized we'd just fall back to doing blocking "async" calls. > and, does it really make sense to have individual GMainContexts per > async operations? > since you have a statefull object already, wouldn't something > like this be better: > > void g_input_stream_set_async_context (GInputStream *stream, >GMainContext *context); > void g_input_stream_async_read(GInputStream *stream, >uint8*buffer, >...); > i.e. here you'd essentially force users to set_async_context() before > any of the g_input_stream_async_*() ops could be called. Yes. This seems like a nicer approach. I had a single read method, but then two wrappers (_read and _read_full) for it so that you didn't alwyas have to pass the NULL context. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a suicidal coffee-fuelled jungle king possessed of the uncanny powers of an insect. She's a radical gypsy socialite with an evil twin sister. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 25 Sep 2006, Alexander Larsson wrote:
> On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
>> On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
>>
>> Hey Alex,
>>
>> Great that you are planning to redesign the VFS.
>>
>>> Here is my current GInputStream:
>>>
>>> struct _GInputStreamClass
>>> {
>>> GObjectClass parent_class;
>>
>> Using GTypeInterfaceClass here would make it much more easy to let
>> library and application developers implement the GInputStream interface
>> in a for-their needs suitable way.
>
> I'm well aware of interfaces. In fact my initial version used an
> interface for this. However, there are other aspects of the equation
> that has to be taken into account to. For instance, using a base class
> means you can inherit functionallity from the baseclass. This makes it
> much easier to implement things, because we can do the fallback async
> wrapper in the base class, and it makes it much easier to do wrapping of
> streams.
not taking side on the interface vs. object issue here. however note, that
you can provide default implementations for interfaces with GType, simply
by hooking up class function pointers in the class_init function passed
when registering the interface type, i.e. just like with object type
registration.
> In fact, if you look at Java and .Net you will see that their streams
> are objects too, not interfaces.
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander LarssonRed Hat, Inc
> [EMAIL PROTECTED][EMAIL PROTECTED]
---
ciaoTJ
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 25 Sep 2006, Alexander Larsson wrote:
> On Mon, 2006-09-25 at 12:04 +0200, Tim Janik wrote:
>> On Wed, 20 Sep 2006, Alexander Larsson wrote:
>>
>>> On Wed, 2006-09-20 at 14:30 +0200, mathieu lacage wrote:
>
>> 2) What is the signature of GDestroyNotify ?
>
> Its already in gtypes.h:
> typedef void(*GDestroyNotify) (gpointer data);
ah. I forgot about this. Don't you think it might make sense for ease of
use to add a void *buffer arg and a GOutputStream * arg to the destroy
notification ?
>>>
>>> Nah, In typical real world cases these would already be in the user_data
>>> object. Say if you're reading a whole file async. It feels better to
>>> keep to the standard glib destroy notifier handling.
>>
>> i have to agree with Mathieu here. not passing the original object handle
>> forces the user to keep tedious etxra data structures around.
>> imagine:
>> struct UserObject {
>>GOutputStream *stream1;
>>GOutputStream *stream2;
>> };
>>
>> naturally, you'd pass UserObject* as gpointer data to the stream.
>> if your notifiers don't also contain the GOutputStream* handle though,
>> the user can't clearly identify stream1 vs. stream2 though, so he'd have to
>> resort to creating helper structures:
>> struct UserObjectOutputStreamCallbackData {
>>UserObject*user_object;
>>GOutputStream *stream:
>> };
>> and allocate/pass/free this instead.
>
> The actual operation callback for an async operation does of course pass
> both the stream and the user data. And it is always called, even on
> cancellation, so the destroy notifier isn't required. The destroy
> notifier is more of an extra freebie to make it simple to add a g_free
> or g_object_unref to free the user object. For a more complicated
> multi-stream setup I think you'd do the handling in the operation
> callbacks.
ah i see, that makes sense, as far as the operation callback is
concerned at least.
> Also, In your example above the extra structure isn't needed. One would
> just use different destroy notifiers for the two streams.
hm, different? you mean you'd encode whether it's stream1 or stream2 in
the destroy notifier callback implementation?
well, that breaks as soon as the user has a non-fixed number:
struct UserObject {
guint n_streams;
GOutputStream **streams;
};
as an anecdotal side note, one case where i originally went for just
having a single data argument in the destroy notifier, and later had
to extend the callback signature to also cover the original object due
to user requests was GWeakNotify.
in your case, i think it's pretty forseeable that passing the object
handle along with the destroy notifier _can_ be useful and is easy to
implement on the caller side. if it's lacking, it's really tedious to
substitute on the user side though, so it'd be best to go with a signature
like that of GWeakNotify from the start.
>> (not providing GOutputStream, but just data, would be a bit like eliminating
>> the instance argument from signal handlers and force people to pass it along
>> as part of the user_data passed in to g_signal_connect() ;)
>
> I don't think so. I.e. for an aync read the callback would look like:
>
> typedef void (*GAsyncReadCallback) (GInputStream *stream,
>void *buffer,
>gsize count_requested,
>gsize count_read,
>gpointer data,
>GError*error);
>
> This callback is similar to the signal handler. The destroy notifier is
> just gravy on top of it.
>
> If we're stretching our comparisons a bit here it would be more like
> having the GDestroyNotifier called for a hashtable entry also pass a
> pointer to the hashtable so that you can destroy the entry differently
> depending on which hashtable it was in. :)
ok, i buy that one. ;)
and frankly, if i were to review the addition of destroy notifiers to
the hash table API *these* days, i'd insist on passing the hash table
along, similar to the instance in GWeakNotify ;)
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander LarssonRed Hat, Inc
> [EMAIL PROTECTED][EMAIL PROTECTED]
---
ciaoTJ
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 12:04 +0200, Tim Janik wrote:
> On Wed, 20 Sep 2006, Alexander Larsson wrote:
>
> > On Wed, 2006-09-20 at 14:30 +0200, mathieu lacage wrote:
> >>>
> 2) What is the signature of GDestroyNotify ?
> >>>
> >>> Its already in gtypes.h:
> >>> typedef void(*GDestroyNotify) (gpointer data);
> >>
> >> ah. I forgot about this. Don't you think it might make sense for ease of
> >> use to add a void *buffer arg and a GOutputStream * arg to the destroy
> >> notification ?
> >
> > Nah, In typical real world cases these would already be in the user_data
> > object. Say if you're reading a whole file async. It feels better to
> > keep to the standard glib destroy notifier handling.
>
> i have to agree with Mathieu here. not passing the original object handle
> forces the user to keep tedious etxra data structures around.
> imagine:
> struct UserObject {
>GOutputStream *stream1;
>GOutputStream *stream2;
> };
>
> naturally, you'd pass UserObject* as gpointer data to the stream.
> if your notifiers don't also contain the GOutputStream* handle though,
> the user can't clearly identify stream1 vs. stream2 though, so he'd have to
> resort to creating helper structures:
> struct UserObjectOutputStreamCallbackData {
>UserObject*user_object;
>GOutputStream *stream:
> };
> and allocate/pass/free this instead.
The actual operation callback for an async operation does of course pass
both the stream and the user data. And it is always called, even on
cancellation, so the destroy notifier isn't required. The destroy
notifier is more of an extra freebie to make it simple to add a g_free
or g_object_unref to free the user object. For a more complicated
multi-stream setup I think you'd do the handling in the operation
callbacks.
Also, In your example above the extra structure isn't needed. One would
just use different destroy notifiers for the two streams.
> (not providing GOutputStream, but just data, would be a bit like eliminating
> the instance argument from signal handlers and force people to pass it along
> as part of the user_data passed in to g_signal_connect() ;)
I don't think so. I.e. for an aync read the callback would look like:
typedef void (*GAsyncReadCallback) (GInputStream *stream,
void *buffer,
gsize count_requested,
gsize count_read,
gpointer data,
GError*error);
This callback is similar to the signal handler. The destroy notifier is
just gravy on top of it.
If we're stretching our comparisons a bit here it would be more like
having the GDestroyNotifier called for a hashtable entry also pass a
pointer to the hashtable so that you can destroy the entry differently
depending on which hashtable it was in. :)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's a lonely drug-addicted Green Beret on the hunt for the last specimen of a
great and near-mythical creature. She's a radical mutant advertising executive
with the soul of a mighty warrior. They fight crime!
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 11:51 +0200, Tim Janik wrote: > I think I see some confusion about the API abstraction layers here. > > Consider the vfs as a switch for the filesystem layer. > > jup, that's exactly what i do. in terms of the unix FS layer, this'd > basically allow every app to provide a FUSE fs for all other apps, > as long as it's running. but in a portable way, since this'll be provided > by GVFS. > > > One of the vfs implementations would be a replacement for the code that > > is currently in gnome-vfs. This would be used on most unix-based system, > > and it will be pluggable similarly to gnome-vfs so that we can extend > > the desktop with new types of file shares or whatever we come up with. > > It would be possible for the gimp to extend this vfs implementation, but > > not on the glib vfs switch level. > > what level exactly would this be then? The glib API (the part used by apps) is a consumer of VFS operations. It abstracts the set of operations required to load, save and enumerate files and information about files. Invisible to the application a specific implementation of this vfs is picked when the vfs is used. The implementation might be a simple local-files version, or it could be a more complicated version using dbus to talk to a daemon that has implementations of things like smb and ftp. The main unix implementation (with the daemons and stuff) will definately let you extend its namespace similar to how gnome-vfs lets you add URI methods. However, the API to extend that vfs will be part of that particular implementation and not part of the generic glib vfs API. What this means is that if Gimp is running on a glib/gtk+ build that only includes the local-files version of the vfs (or a hypothetical win32-native vfs) then the gimp will not be able to use the glib APIs to extend the vfs. Of course, none of this means that the Gimp can't create a GInputStream subclass and use it internally however it wants. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a scarfaced albino stage actor fleeing from a secret government programme. She's a radical paranoid journalist with only herself to blame. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 20 Sep 2006, Alexander Larsson wrote:
> On Wed, 2006-09-20 at 14:30 +0200, mathieu lacage wrote:
>>>
2) What is the signature of GDestroyNotify ?
>>>
>>> Its already in gtypes.h:
>>> typedef void(*GDestroyNotify) (gpointer data);
>>
>> ah. I forgot about this. Don't you think it might make sense for ease of
>> use to add a void *buffer arg and a GOutputStream * arg to the destroy
>> notification ?
>
> Nah, In typical real world cases these would already be in the user_data
> object. Say if you're reading a whole file async. It feels better to
> keep to the standard glib destroy notifier handling.
i have to agree with Mathieu here. not passing the original object handle
forces the user to keep tedious etxra data structures around.
imagine:
struct UserObject {
GOutputStream *stream1;
GOutputStream *stream2;
};
naturally, you'd pass UserObject* as gpointer data to the stream.
if your notifiers don't also contain the GOutputStream* handle though,
the user can't clearly identify stream1 vs. stream2 though, so he'd have to
resort to creating helper structures:
struct UserObjectOutputStreamCallbackData {
UserObject*user_object;
GOutputStream *stream:
};
and allocate/pass/free this instead.
both APIs are possible, it's just that passing the original stream handle
along makes life way simpler for the callback implementer. (though passing
around a buffer handle is not useful i think, it wouldn't even match all
asnyc ops).
(not providing GOutputStream, but just data, would be a bit like eliminating
the instance argument from signal handlers and force people to pass it along
as part of the user_data passed in to g_signal_connect() ;)
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander LarssonRed Hat, Inc
> [EMAIL PROTECTED][EMAIL PROTECTED]
---
ciaoTJ
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 25 Sep 2006, Alexander Larsson wrote: > On Mon, 2006-09-25 at 11:17 +0200, Tim Janik wrote: > >> i haven't seen API proposals yet (allthough i haven't managed to read through >> all of this thread yet either ;) so please bear with me if this is covered >> by your ideas already... >> >> to allow applications to extend on the mechanisms and facilities a new GVFS >> layer will provide, and to support development of experimental backend >> libraries, it could be interesting if the backend plugging API was easy >> enough >> to be implemented by moderately complex applications. >> >> so for instance gimp could register an introspection backend that'd allow >> you to list/read //.network/process/localhost/gimp:$PID/procedures/*/info or >> //.network/process/localhost/gimp:$PID/images (provided an instance is >> running >> and has images loaded). >> >> i'm not saying that the above gimp example is the most prominent use case, >> or even all that important to implement. it's just there to get the idea >> across, that it'd be nice if apps also could easily register some of their >> own (data production) services as URI/VRI schemes. since a libglibvfs library >> would have to implement neccessary means anyway to communicate with a system/ >> user wide daemon to implement your proposal, being able to also use this >> layer as a producer rather than just a consumer for files/data comes as a >> natural extension. > > I'm not quite sure what you mean here. Would the gimp application extend > the vfs inside the application, or would it ship with a plugin to the > vfs layer so that other applications can read the gimp state? i dont know what API you have in mind here, so i'm not sure whether gimp had to install a plugin here... but yes, the basic idea is to have the GVFS layer easily allow apps to provide their own input/output-stream/etc. implementations. so that if gimp starts up, it can register a GVFS backend object/class to e.g. list it's procedures and access procedure->blurb as files. yes, that could be used by other apps to read current gimp state, provided the GVFS daemon is running (since libgvfs would connect to that daemon anyway if it's up). > I think I see some confusion about the API abstraction layers here. > Consider the vfs as a switch for the filesystem layer. jup, that's exactly what i do. in terms of the unix FS layer, this'd basically allow every app to provide a FUSE fs for all other apps, as long as it's running. but in a portable way, since this'll be provided by GVFS. > One of the vfs implementations would be a replacement for the code that > is currently in gnome-vfs. This would be used on most unix-based system, > and it will be pluggable similarly to gnome-vfs so that we can extend > the desktop with new types of file shares or whatever we come up with. > It would be possible for the gimp to extend this vfs implementation, but > not on the glib vfs switch level. what level exactly would this be then? > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander LarssonRed Hat, Inc > [EMAIL PROTECTED][EMAIL PROTECTED] --- ciaoTJ ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 20 Sep 2006, Alexander Larsson wrote:
> Here is my current GInputStream:
>
> struct _GInputStreamClass
> {
> GObjectClass parent_class;
>
> /* Sync ops: */
>
> gssize (* read)(GInputStream *stream,
> void *buffer,
> gsize count,
> GError **error);
> gssize (* skip)(GInputStream *stream,
> gsize count,
> GError **error);
> gboolean (* close) (GInputStream *stream,
> GError **error);
>
> /* Async ops: (optional in derived classes) */
> guint(* read_async) (GInputStream *stream,
> void *buffer,
> gsize count,
> int io_priority,
> GMainContext *context,
> GAsyncReadCallback callback,
> gpointerdata,
> GDestroyNotify notify);
> guint(* close_async) (GInputStream *stream,
> GMainContext *context,
> GAsyncCloseCallback callback,
> gpointerdata,
> GDestroyNotify notify);
> void (* cancel) (GInputStream *stream,
> guint tag);
> }
>
> GInputStream objects can optionally also implement the GSeekable
> interface to support seeking and truncating. This is your basic
> syncronous read API with an addition of some async calls. If a derived
> class doesn't implement the async calls the baseclass will emulate them
> using threads (similar to how gnome-vfs works now). GOutputStream is
> similar, without the skip method, but with a flush method added.
hm, in your initial proposal, you said that apps don't currently have control
over whether they want to use/care about threading or not. so, are you
planning for a way to use the GVFS API without threading under the hood?
then, emulation of the above asny calls would be implemented in terms of
IO handlers attached to the provided GMainContext *context?
and, does it really make sense to have individual GMainContexts per
async operations?
since you have a statefull object already, wouldn't something
like this be better:
voidg_input_stream_set_async_context (GInputStream *stream,
GMainContext *context);
voidg_input_stream_async_read(GInputStream *stream,
uint8*buffer,
...);
i.e. here you'd essentially force users to set_async_context() before
any of the g_input_stream_async_*() ops could be called.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander LarssonRed Hat, Inc
> [EMAIL PROTECTED][EMAIL PROTECTED]
---
ciaoTJ
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 11:17 +0200, Tim Janik wrote: > i haven't seen API proposals yet (allthough i haven't managed to read through > all of this thread yet either ;) so please bear with me if this is covered > by your ideas already... > > to allow applications to extend on the mechanisms and facilities a new GVFS > layer will provide, and to support development of experimental backend > libraries, it could be interesting if the backend plugging API was easy enough > to be implemented by moderately complex applications. > > so for instance gimp could register an introspection backend that'd allow > you to list/read //.network/process/localhost/gimp:$PID/procedures/*/info or > //.network/process/localhost/gimp:$PID/images (provided an instance is running > and has images loaded). > > i'm not saying that the above gimp example is the most prominent use case, > or even all that important to implement. it's just there to get the idea > across, that it'd be nice if apps also could easily register some of their > own (data production) services as URI/VRI schemes. since a libglibvfs library > would have to implement neccessary means anyway to communicate with a system/ > user wide daemon to implement your proposal, being able to also use this > layer as a producer rather than just a consumer for files/data comes as a > natural extension. I'm not quite sure what you mean here. Would the gimp application extend the vfs inside the application, or would it ship with a plugin to the vfs layer so that other applications can read the gimp state? I think I see some confusion about the API abstraction layers here. Consider the vfs as a switch for the filesystem layer. An application only uses the vfs layer, and is ignorant of what happens underneath it. This allows us to switch out parts. Any version always have vfs support to access local files, so apps can use this without enforcing bloat. Then specially built versions of gtk+ would use a specific implementation of the vfs allowing applications to seamlessly access more files. For instance, a win32 build of gtk+ could include a vfs layer that uses the win32 shell extensions, allowing gtk+ apps to read files on e.g. bluetooth phones (using the native win32 support for this). One of the vfs implementations would be a replacement for the code that is currently in gnome-vfs. This would be used on most unix-based system, and it will be pluggable similarly to gnome-vfs so that we can extend the desktop with new types of file shares or whatever we come up with. It would be possible for the gimp to extend this vfs implementation, but not on the glib vfs switch level. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an all-American voodoo filmmaker on the hunt for the last specimen of a great and near-mythical creature. She's an elegant communist college professor with someone else's memories. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 20 Sep 2006, Alexander Larsson wrote: > From just reading your post, without deeper insight into what you mean I > would be hesitant to add something like that to glib. Its not clear that > applications need it, and its not clear the the solution we create is > good enough for the applications that need something like it (in fact, I > think its likely that such apps want to do their own thing). > Furthermore, its not a well understood area, and as such I think its a > bad idea to try to integrate with the basic platform that has guaranteed > stability and high quality requirements. Having it as a library outside > glib makes it possible to experiment with and develop the idea. i haven't seen API proposals yet (allthough i haven't managed to read through all of this thread yet either ;) so please bear with me if this is covered by your ideas already... to allow applications to extend on the mechanisms and facilities a new GVFS layer will provide, and to support development of experimental backend libraries, it could be interesting if the backend plugging API was easy enough to be implemented by moderately complex applications. so for instance gimp could register an introspection backend that'd allow you to list/read //.network/process/localhost/gimp:$PID/procedures/*/info or //.network/process/localhost/gimp:$PID/images (provided an instance is running and has images loaded). i'm not saying that the above gimp example is the most prominent use case, or even all that important to implement. it's just there to get the idea across, that it'd be nice if apps also could easily register some of their own (data production) services as URI/VRI schemes. since a libglibvfs library would have to implement neccessary means anyway to communicate with a system/ user wide daemon to implement your proposal, being able to also use this layer as a producer rather than just a consumer for files/data comes as a natural extension. > Alexander LarssonRed Hat, Inc > [EMAIL PROTECTED][EMAIL PROTECTED] --- ciaoTJ ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
May a newbie Windows convert make a suggestion or two ? 1) Could you please make it stop telling me I'm wrong ? For example :- I'm trying to get to grips with monodevelop and I save some data out as xml, with .txt extension. I do this to make it easier to hand edit to insert specifically malformed bogus test cases before re-loading it into my test application. Double clicking on the "myxmlfile.txt" results : Expected Launch gedit and read in the file. Actual It tries to tell me I'm wrong Ok so try to open it in gedit and gedit just wines about it's type ! Please tell me how to tell it easily that I *seriously* want it treated as a text file or as a csv or as anything I tell it whenever I say so - how dare it try to out guess me! By all means notify me in the properties for the file, but otherwise please tell me how to make it do as it's told ! 2) Could you get it to mount the file systems so that they are available from the shell as well as the gui ? Sorry, this is another Windows hangover, but is none the less incredibly frustrating. I have no idea how anyone else works around these, but to smooth the transition for some of us former Microsoft users these may help. Best Regards Matthew Snook ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Sat, 2006-09-23 at 21:06 +0200, Reiner Jung wrote: > > As pointed out a high-level vfs must support a more object-oriented > view to files. I think, we should stop thinking of files in a > hierarchical file system and start using the term document or > (information) object ... because classical file systems are going > south. Things like Beagle, the MacOS search thingy or the database > based Windows file system (which will be released just after the hurd, > I am absolutely sure) are pointing in a different way of organizing > information. I think that there is interesting research and ideas in the generalization of filesystems and new abstractions for it. However, this is not yet a well known area where we can reliably come up with a system that will work well and be useful to users. Furthermore, I don't see the current file sharing systems such as SMB, NFS, FTP, DAV, etc go away anytime soon, and we absolutely need a solid system to handle those, which is what I'm proposing. If anyone wants to work on something like what you propose that is great, and I applaud them. But it doesn't replace the VFS, nor does it have to be implemented at that level. I'm personally slightly worried that what you describe is very similar to the WinFS approach that seems to have failed even with the enourmous resources thrown at it by Microsoft. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an unconventional voodoo paranormal investigator with a robot buddy named Sparky. She's a violent mute bodyguard with an MBA from Harvard. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Sun, 2006-09-24 at 22:49 -0400, Dan Winship wrote: > Alexander Larsson wrote: > > The only disadvantages I see [with IRIs] are: > > > > 1) The mapping to FUSE filenames will be less intuitive > > "Intuitive" is less important than "able to be figured out > programmatically", which shouldn't be a problem. Also, it will still be > intuitive in the case where the filesystem uses a single charset for all > filenames, right? If so, then this doesn't seem that bad. Yeah, its not that bad. > > 2) We can't implement simple kio and gnome-vfs modules that > > automatically support all gvfs files. Instead we have to continue to > > rely on hoping %u being in the desktop file means all applications > > support the same type of URIs. (Which isn't true) > > There might also be problems with IRI-based gvfs and URI-based gnome-vfs > wanting to using different URLs to refer to the same file? Thats already possible in thousands of ways. You can use different case for hex escape, escape various sets of chars, add "/./" to the path, etc, etc. Non-canonicalized URIs are very much not unique. Even canonicalized ones can refer to the same object with for instance dns aliasing or symlinks. > For gnome-vfs though, we ought to be able to solve both problems if we > just accompany the gvfs release with an updated gnome-vfs that tries to > defer to gvfs wherever possible rather than using its own modules. That is be possible, but could end up being quite a bit more work, especially if you want to handle authentication/mounting in the gnome-vfs method. Another approach is to just use the old gnome-vfs and rely on using the same form of URIs for the new vfs. > > 3) Windows doesn't use uris as its shell namespace, so we have to make > > up some sort of gtk-specific mapping from their identifiers to some > > custom uri scheme. We could just not support windows shell extensions, > > but it would be nice to access things like "My Documents" properly. > > Is "My Documents" really needed anywhere other than in the file chooser? > If we still have multiple GtkFilesystem implementations, then > GtkFilesystemWin32 could handle translating Windows Shell extensions > into the corresponding real filesystem paths. Not all windows shell extensions map into real filesystem paths though. For instance if you install bluetooth stuff that can browse your phone in explorer that will be handled by a windows shell extensions. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an otherworldly small-town barbarian fleeing from a secret government programme. She's a brilliant African-American detective living on borrowed time. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Handling of connection-specific parameters (was: Re: Plans for gnome-vfs replacement)
On Sun, 2006-09-24 at 13:27 +0200, Christian Neumair wrote: > Am Freitag, den 22.09.2006, 16:18 +0200 schrieb Alexander Larsson: > > Actually, it still problematic in some cases. Consider a network share > > (say ftp) that somehow (via prefs or the protocol) specifies what > > encoding its filenames are in. The problem is that not all filenames > > might be valid in this encoding (for instance, the server says > > everything is in utf-8 but one file is in latin-1). > > How do you plan to implement connection- or mount-specific parameters? > This includes things like network compression levels, whether the login > directory instead of the actual FS root should be used as URI/IRI > basename, maybe whether the target should be mounted r/o etc.. I haven't thought at all about the storage of it yet. It sort of depends on exactly how we handle the mounting. > Maybe these properties could be exposed via D-Bus, and we'd get > protocol-specific key/value/tooltip triples which can be used in a GUI. There would be something like GnomeVFSVolumeManager around. That will give us an API to keep track of all mounted filesystems and expose whatever features are required. > I used to play around with ideas for allowing full connection > serialization into URIs/IRIs, i.e. > environment:opt1=foo&opt2=bar&opt3=foobar#protocol:/// but I wonder how > applicable this is, taken that there are drafts around specifying > another syntax, for instance for SFTP connection parameters [1]: I'd prefer to disentangle this from the URI aspect instead of complicating our relation to URIs further. I haven't given much thought to the storage format, but anything that lets us store key-value pairs should work imho. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a scarfaced chivalrous librarian She's an orphaned belly-dancing archaeologist with a birthmark shaped like Liberty's torch. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Fri, 2006-09-22 at 10:48 -0400, Dimi Paun wrote: > On Fri, September 22, 2006 10:18 am, Alexander Larsson wrote: > > So, IRIs are better than URIs, but not perfect. They might still be our > > best choice though. > > I agree. AFAIU, IRIs will be used mostly for the case when people > want to type the filename directly. Few things to keep in mind: > -- a small percentage of users will use this. While typing the > file directly is often requested (and I fall in that camp), > it is mostly relevant for local file paths. > -- even if we cover only 90% of filenames with IRIs, it's still > OK, since the user can always browse to the file in those > exceptional cases. > > Put the two togeter, and you have only a _tiny_ fraction of cases > where we might have problems. For this reason I maintain that we > should stick to well known concepts: > -- standard naming schemes: IRIs are great, since they behave > as normal people would expect URI to behave (except maybe > for the restricted set of chars). > -- in most (all?) cases where we would be using IRIs, there > is no ambiguity in allowing even the unallowed IRIs > chars (like space, etc.) and simply escape them automatically. > This will make them even more usable to the regular folk. Yeah, I agree. > On the IRI's restricted char set, I would like to point out that > they exist to make IRIs (easily) usable by programs. When _users_ > interact with IRIs though (like in the location bar), there is no > ambiguity whatsoever if we lift all such restrictions. For this > reason, users get upset (and rightly so) if they type stuff unescaped > and it doesn't work for reasons that they don't really care about > (or can't even imagine for that matter). I don't think thats the primary reason for them. The primary reason for not allowing e.g. space in an IRI is that the details of such whitespace could be lost if you transfer the IRI over e.g. printed line-wrappend media. > Do I understand correctly that IRIs will be used (by and large) just > in Nautilus location bar and the Open File Dialog location bar? Yeah. Thats the only place I can think of for it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a fast talking amnesiac romance novelist with a secret. She's an enchanted tomboy single mother with an MBA from Harvard. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
> On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
>
> Hey Alex,
>
> Great that you are planning to redesign the VFS.
>
> > Here is my current GInputStream:
> >
> > struct _GInputStreamClass
> > {
> > GObjectClass parent_class;
>
> Using GTypeInterfaceClass here would make it much more easy to let
> library and application developers implement the GInputStream interface
> in a for-their needs suitable way.
I'm well aware of interfaces. In fact my initial version used an
interface for this. However, there are other aspects of the equation
that has to be taken into account to. For instance, using a base class
means you can inherit functionallity from the baseclass. This makes it
much easier to implement things, because we can do the fallback async
wrapper in the base class, and it makes it much easier to do wrapping of
streams.
In fact, if you look at Java and .Net you will see that their streams
are objects too, not interfaces.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's a suave Catholic senator from the Mississippi delta. She's a
strong-willed gold-digging hooker living on borrowed time. They fight crime!
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
Alexander Larsson wrote: > The only disadvantages I see [with IRIs] are: > > 1) The mapping to FUSE filenames will be less intuitive "Intuitive" is less important than "able to be figured out programmatically", which shouldn't be a problem. Also, it will still be intuitive in the case where the filesystem uses a single charset for all filenames, right? If so, then this doesn't seem that bad. > 2) We can't implement simple kio and gnome-vfs modules that > automatically support all gvfs files. Instead we have to continue to > rely on hoping %u being in the desktop file means all applications > support the same type of URIs. (Which isn't true) There might also be problems with IRI-based gvfs and URI-based gnome-vfs wanting to using different URLs to refer to the same file? For gnome-vfs though, we ought to be able to solve both problems if we just accompany the gvfs release with an updated gnome-vfs that tries to defer to gvfs wherever possible rather than using its own modules. > 3) Windows doesn't use uris as its shell namespace, so we have to make > up some sort of gtk-specific mapping from their identifiers to some > custom uri scheme. We could just not support windows shell extensions, > but it would be nice to access things like "My Documents" properly. Is "My Documents" really needed anywhere other than in the file chooser? If we still have multiple GtkFilesystem implementations, then GtkFilesystemWin32 could handle translating Windows Shell extensions into the corresponding real filesystem paths. -- Dan ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Sun, 2006-09-24 at 14:51 +0200, Philip Van Hoof wrote:
> #define G_INPUT_STREAM_GET_IFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE
> ((inst), G_TYPE_INPUT_STREAM, TnyDeviceIface))
Search and replace issue. This should of course be something like:
#define G_INPUT_STREAM_GET_IFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE
((inst), G_TYPE_INPUT_STREAM, GInputStreamIface))
> #define G_SEEKABLE_GET_IFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE ((inst),
> G_TYPE_SEEKABLE, TnyDeviceIface))
And this one GSeekableIface
Also note that I would definitely start with a base GStreamIface,
continue with a GInputStreamIface and a GOutputStreamIface where the
input and output have as prerequisite the GStreamIface.
Or in .NET (and Java) that would mean:
namespace G {
interface IStreamIface { .. }
interface IOutputStream : G.IStreamIface { .. }
interface IInputStream : G.IStreamIface { .. }
interface ISeekable : G.IStreamIface { .. }
/* OR: interface ISeekable { .. }; */
}
In Java I think you can only extend an interface with one interface.
In .NET I know you can extend an interface with as much other interfaces
as you want.
Extending an interface is more or less the exact same thing as copy
pasting all the to-implement methods and properties (properties
translate to both a get and a set method in Java, depends on whether or
not it's a read-only property etc etc) in the final interface.
And now you would create a SomeStreamType like this:
public class SomeStreamType : G.IOutputStream, G.IInputStream, G.ISeekable
{
}
ps. To the Java warriors on this list: forgive me for my .NET style
syntax. I know you guys know it's all the same (Java and .NET) with just
a little bit different syntax sugar.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
> > Here is my current GInputStream:
> >
> > struct _GInputStreamClass
> > {
> > GObjectClass parent_class;
>
> Using GTypeInterfaceClass here would make it much more easy to let
> library and application developers implement the GInputStream interface
> in a for-their needs suitable way.
Also look at these prior art thingies:
http://tinymail.org/API/libtinymail-1.0/libtinymail-tny-stream.html
http://pvanhoof.be/files/libcamel-api/html/CamelStream.html
http://pvanhoof.be/files/libcamel-api/html/CamelSeekableStream.html
I know this API proposal MIGHT sound more complex. In reality, it most
certainly isn't. Just try it out. Fiddle around with it. Or see how I in
tinymail (and notzed and fejj in Camel) used something like this.
#ifndef _G_INPUT_STREAM_H
#define _G_INPUT_STREAM_H
#include
#include
G_BEGIN_DECLS
typedef struct _GInputStream GInputStream;
typedef struct _GInputStreamIface GInputStreamIface;
#define G_TYPE_INPUT_STREAM (g_input_stream_get_type ())
#define G_INPUT_STREAM(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj),
G_TYPE_INPUT_STREAM, GInputStream))
#define G_IS_INPUT_STREAM(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj),
G_TYPE_INPUT_STREAM))
#define G_INPUT_STREAM_GET_IFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE ((inst),
G_TYPE_INPUT_STREAM, TnyDeviceIface))
struct _GInputStreamIface
{
GTypeInterface parent_iface;
/* Sync ops: */
gssize (* read)(GInputStream *stream,
void *buffer,
gsize count,
GError **error);
gssize (* skip)(GInputStream *stream,
gsize count,
GError **error);
gboolean (* close) (GInputStream *stream,
GError **error);
/* Async ops: (optional in derived classes) */
guint(* read_async) (GInputStream *stream,
void *buffer,
gsize count,
int io_priority,
GMainContext *context,
GAsyncReadCallback callback,
gpointerdata,
GDestroyNotify notify);
guint(* close_async) (GInputStream *stream,
GMainContext *context,
GAsyncCloseCallback callback,
gpointerdata,
GDestroyNotify notify);
void (* cancel) (GInputStream *stream,
guint tag);
}
GType g_input_stream_get_type (void);
gssize g_input_stream_read (GInputStream *stream,
void *buffer,
gsize count,
GError **error);
gssize g_input_stream_skip (GInputStream *stream,
gsize count,
GError **error);
gboolean g_input_stream_close (GInputStream *stream,
GError **error);
guint g_input_stream_read_async (GInputStream *stream,
void *buffer,
gsize count,
int io_priority,
GMainContext *context,
GAsyncReadCallback callback,
gpointerdata,
GDestroyNotify notify);
guint g_input_stream_close_async (GInputStream *stream,
GMainContext *context,
GAsyncCloseCallback callback,
gpointerdata,
GDestroyNotify notify);
void g_input_stream_cancel (GInputStream *stream,
guint tag);
G_END_DECLS
#endif
#ifndef _G_SEEKABLE_H
#define _G_SEEKABLE_H
#include
#include
G_BEGIN_DECLS
typedef struct _GSeekable GSeekable;
typedef struct _GSeekableIface GSeekableIface;
#define G_TYPE_SEEKABLE (g_seekable_get_type ())
#define G_SEEKABLE(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj),
G_TYPE_SEEKABLE, GSeekable))
#define G_IS_SEEKABLE(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj),
G_TYPE_SEEKABLE))
#define G_SEEKABLE_GET_IFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE ((inst),
G_TYPE_SEEKABLE, TnyDeviceIface))
struct _GSeekableIface
{
GTypeInterface parent_iface;
off_t (*seek) (GSeekable *self, off_t offset, GSeekPolicy policy);
off_t (*tell) (GSeekable *stream);
}
GType g_seekable_get_type (void);
off_t g_seekable_seek (GSeekable *self, off_t offset, GSeekPolicy policy);
off_t g_seekable
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
Hey Alex,
Great that you are planning to redesign the VFS.
> Here is my current GInputStream:
>
> struct _GInputStreamClass
> {
> GObjectClass parent_class;
Using GTypeInterfaceClass here would make it much more easy to let
library and application developers implement the GInputStream interface
in a for-their needs suitable way.
Because the gtype system has infrastructure that makes it more easy.
Using a GObject it would also be a lot more difficult to let such a type
implement multiple interfaces: the developer would have to inherit.
Unless in C++, you can't multi-inherit in most programming languages.
Language binding generators like gapi and pygtk's one know how to deal
with GTypeInterface. For example by putting define-virtual in the defs
file of a Python language binding generation helper-files, it would be
easy and possible to implement a GInputStream in Python.
In .NET it wouldn't (not at this moment) be possible to use the
GTypeInterface as a real "interface" as known in the .NET world. Nor
could a Java language binding do this (as this would require significant
adaptations to both the compiler and virtual machine of the
environment), but I know there's plans to ease creating language
bindings for situations like these. For example by creating an abstract
class where the developer has to implement the methods.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Handling of connection-specific parameters (was: Re: Plans for gnome-vfs replacement)
Am Freitag, den 22.09.2006, 16:18 +0200 schrieb Alexander Larsson: > Actually, it still problematic in some cases. Consider a network share > (say ftp) that somehow (via prefs or the protocol) specifies what > encoding its filenames are in. The problem is that not all filenames > might be valid in this encoding (for instance, the server says > everything is in utf-8 but one file is in latin-1). How do you plan to implement connection- or mount-specific parameters? This includes things like network compression levels, whether the login directory instead of the actual FS root should be used as URI/IRI basename, maybe whether the target should be mounted r/o etc.. Maybe these properties could be exposed via D-Bus, and we'd get protocol-specific key/value/tooltip triples which can be used in a GUI. There would then also include attributes applicable for all mounts, like a user-visible display name, an icon name etc. After all, we get lots of user requests for VFS mount renaming caps. Do you have any idea on the storage of this data? I used to play around with ideas for allowing full connection serialization into URIs/IRIs, i.e. environment:opt1=foo&opt2=bar&opt3=foobar#protocol:/// but I wonder how applicable this is, taken that there are drafts around specifying another syntax, for instance for SFTP connection parameters [1]: sftp_URI = "sftp://"; [ userinfo "@" ] host [ ":" port ] [;conn-parameter=value] [ abs_path ] [;sftp-parameter=value] [1] http://tools.ietf.org/html/draft-ietf-secsh-scp-sftp-ssh-uri-00 -- Christian Neumair <[EMAIL PROTECTED]> ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everyone, I've read the initial mail on this subject from Alexander Larsson this evening and found it quite uplifting. I've thought for a long time (actually since I've tried to use gnome-vfs the first time) that if might be a good idea to replace this layer by something new. And some time later I saw on freedesktop.org (http://www.freedesktop.org/wiki/Software_2fdvfs) an attempt to generate a standardized library for KDE and GNOME, so I was satisfied and hoped the issue would be solved soon. And I lost track of it, due to other work issues. So today I've read this mail and due to my background in (operating) system design, I thought this is a good idea. (Also I've heard it elsewhere in the gnome community, I don't know where.) And it reminded me at some OS-design lesson some years ago. Put file services in user space. That is what this concept is all about. Alexander mentioned a list of problems the actual system have. Also he provided a some use cases and features the new system must have. At this point I want to add some thoughts to this topic. As pointed out a high-level vfs must support a more object-oriented view to files. I think, we should stop thinking of files in a hierarchical file system and start using the term document or (information) object ... because classical file systems are going south. Things like Beagle, the MacOS search thingy or the database based Windows file system (which will be released just after the hurd, I am absolutely sure) are pointing in a different way of organizing information. We have contact (objects) and mails (objects) which have properties like addresses which are linked to properties of a contact. The same thing you can find in papers, books and all other information like music or movies. In such a context to identify an object is best done by a descriptor handle (id) as A. already pointed out. If you look for instance at the Eclipse Java framework. The files there are represented by an identifier object which could return a URI but in general the API allows to return other location descriptors as well. Which is very useful if you connect the system to a database :-) At least I see a problem with his idea to use gobjects in this implementation. If this service should be cross-desktop-environment then gobject is not such a good idea. KDE uses a different object model (as far as I know they use C++) and it is very unlikely that they want to use gobject in there applications. To solve this (at least in parts) I suggest defining a protocol for the gnome-vfs-daemon which is implementation independent so a KDE client could be implemented without using glib or any other lib out of this context. This implies that using RPCs on gobjects in the daemon wouldn't be a good idea. But RPCs are not faster as other local IPC as such. So this is not a really bad thing. As such I would propose (I know A. already did that more or less) a client side library which knows the necessary high-level operations for data objects (libvfs-client.so), a server (vfs-daemon) with separate processes for each volume or maybe better each data-object (file) it handles. This daemon should have a plug-in interface like gstreamer for different volume types. So it could be compiled without linking it with hundreds of libraries. The rights management should not be the job of the daemon in the way that it have direct access to the keyring but it should be possible to remember security information on a session base. Here is a (somewhat strange) example of a session. - - The user clicks on a share (database located at NSA headquarter) - - The object manager (nautilus) instructs the vfs-daemon to mount the remote share. - - The NSA requests for a retina print so the vfs-daemon asks nautilus for that. - - Nautilus recognizes the reply to be an authentication request and asks the local auth. service to get the information. - - The auth. service (e.g. gnome key manager) instructs the user to look at the retina scanner and returns the information to Nautilus which delivers the information to vfs-daemon. - - The vfs-daemon sends the information directly to the NSA to finish the log on. - - Until the user unmounts the share, the vfs-daemon does everything to keep the share open and accessible for all applications of the user. (session based handling) At this point, I think this shouldn't be all applications because some applications (e-mail client, web browser) run on another security level. So it might be wise to allow only certain applications the access of this share. So all application which want to use the share must know a specific token. Such features are not available on Linux systems (as far as I know) right now, but in the near future this could be important. In reply to Paolo, who mentioned that it is not clear to him if Alexander is aiming for high-level interface and a low-level stream-based system. A Look at the Java
Re: Plans for gnome-vfs replacement
On Fri, September 22, 2006 10:18 am, Alexander Larsson wrote: > So, IRIs are better than URIs, but not perfect. They might still be our > best choice though. I agree. AFAIU, IRIs will be used mostly for the case when people want to type the filename directly. Few things to keep in mind: -- a small percentage of users will use this. While typing the file directly is often requested (and I fall in that camp), it is mostly relevant for local file paths. -- even if we cover only 90% of filenames with IRIs, it's still OK, since the user can always browse to the file in those exceptional cases. Put the two togeter, and you have only a _tiny_ fraction of cases where we might have problems. For this reason I maintain that we should stick to well known concepts: -- standard naming schemes: IRIs are great, since they behave as normal people would expect URI to behave (except maybe for the restricted set of chars). -- in most (all?) cases where we would be using IRIs, there is no ambiguity in allowing even the unallowed IRIs chars (like space, etc.) and simply escape them automatically. This will make them even more usable to the regular folk. On the IRI's restricted char set, I would like to point out that they exist to make IRIs (easily) usable by programs. When _users_ interact with IRIs though (like in the location bar), there is no ambiguity whatsoever if we lift all such restrictions. For this reason, users get upset (and rightly so) if they type stuff unescaped and it doesn't work for reasons that they don't really care about (or can't even imagine for that matter). Do I understand correctly that IRIs will be used (by and large) just in Nautilus location bar and the Open File Dialog location bar? -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc. ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Fri, 2006-09-22 at 14:01 +0200, Alexander Larsson wrote: > On Fri, 2006-09-22 at 10:53 +0200, Alexander Larsson wrote: > > On Fri, 2006-09-22 at 10:49 +0200, Alexander Larsson wrote: > > > > > I see that there has been no update to the lastest verson of the draft, > > > even if it expires 31 May 2005. Does anyone know the status of this? > > > > I spoke to quickly. This is now RFC 3987 since January 2005: > > http://www.ietf.org/rfc/rfc3987.txt > > Ok. I've studied this a bit, and i think it would be quite possible to > use URIs as the lowlever serialization form (i.e. what is passed between > apps as commandline arguments, and DnD), but use absolute filenames if > posible, and otherwise IRIs in the nautilus/file-selector location > entry. Actually, it still problematic in some cases. Consider a network share (say ftp) that somehow (via prefs or the protocol) specifies what encoding its filenames are in. The problem is that not all filenames might be valid in this encoding (for instance, the server says everything is in utf-8 but one file is in latin-1). If we want to use URIs we have to use the raw values of the filenames and escape them. We can't do the conversion to utf8 for the uri, because the conversion might fail, which would mean there are some files that we can't specify via uris. Which means we can't for instance rename them correctly or delete them. Since the IRIs are directly mapped to/from URIs we can only create nicely readable IRIs in the case where the URI really uses utf8 for its encoding. There are some cases where the URIs aren't UTF8, but we know what encoding they are, so we could potentially show the filenames nicer, like the above case where the FTP site specifying latin-1 or local files with G_BROKEN_FILENAMES set. All is not lost though, even though we can't produce nice looking URIs in these cases we can at least use our knowledge of the remote encoding to get readable display names in the file selector and file manager views, as these names doesn't have to losslessly round trip. So, IRIs are better than URIs, but not perfect. They might still be our best choice though. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a bookish Jewish shaman on a mission from God. She's an elegant tomboy college professor who hides her beauty behind a pair of thick-framed spectacles. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Fri, 2006-09-22 at 10:53 +0200, Alexander Larsson wrote: > On Fri, 2006-09-22 at 10:49 +0200, Alexander Larsson wrote: > > > I see that there has been no update to the lastest verson of the draft, > > even if it expires 31 May 2005. Does anyone know the status of this? > > I spoke to quickly. This is now RFC 3987 since January 2005: > http://www.ietf.org/rfc/rfc3987.txt Ok. I've studied this a bit, and i think it would be quite possible to use URIs as the lowlever serialization form (i.e. what is passed between apps as commandline arguments, and DnD), but use absolute filenames if posible, and otherwise IRIs in the nautilus/file-selector location entry. Not only is this standardized and likely to be used more and more, its also already supported in e.g. firefox. The only disadvantages I see are: 1) The mapping to FUSE filenames will be less intuitive 2) We can't implement simple kio and gnome-vfs modules that automatically supports all gvfs files. Instead we have to continue to rely on hoping %u being in the desktop file means all applications support the same type of URIs. (Which isn't true) 3) Windows doesn't use uris as its shell namespace, so we have to make up some sort of gtk-specific mapping from their identifiers to some custom uri scheme. We could just not support windows shell extensions, but it would be nice to access things like "My Documents" properly. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an otherworldly crooked inventor with acid for blood. She's an elegant hip-hop single mother descended from a line of powerful witches. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Fri, 2006-09-22 at 10:49 +0200, Alexander Larsson wrote: > I see that there has been no update to the lastest verson of the draft, > even if it expires 31 May 2005. Does anyone know the status of this? I spoke to quickly. This is now RFC 3987 since January 2005: http://www.ietf.org/rfc/rfc3987.txt =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a genetically engineered shark-wrestling astronaut who hangs with the wrong crowd. She's a blind renegade magician's assistant in the witness protection program. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Thu, 2006-09-21 at 20:03 +0100, Alex Jones wrote:
> Hi list
>
> On Thu, 2006-09-21 at 11:26 -0400, Dimi Paun wrote:
> > On Thu, September 21, 2006 10:47 am, Alexander Larsson wrote:
> > > One solution would be to use some other prefix than / for
> > > non-local files, and to use some form of escaping only for non-utf8
> > > chars and non-printables. This works since we only handle absolute
> > > pathnames, so anything not starting with / is out of band.
> >
> > I think this is a sippery slope -- a new form of URI which is
> > the same but a bit different will be very confusing. I took the
> > general population 10 years to grok a tiny bit of the URI concept,
> > and most people still don't get it. The techinical points about
> > escaping and so on are so foreign to most folks that they will
> > be utterly confused (and very annoyed) that they can't enter
> > an unescaped URI.
> >
> > I agree that the fully escaped URI is insane for an interface
> > with the user. That's clearly just an internal notation. Howerver,
> > for folks that understand URI enough to type them directly in
> > text (which is very seldom even for people that do understand
> > them simply because they are usually long enough that typos are
> > very likely), we can just simply accept improper URIs unescaped
> > and escape them internally ourselves. Whatever we do, this is not
> > really a use case that's common, no need to optimize for it.
>
> IRI's can be used for this. IRIs are directly mapped to URIs by
> escaping.
IRI's look interesting. They are basically the same as the "unescaped
utf8 uris" i gave as an example above, but formalized.
I see that there has been no update to the lastest verson of the draft,
even if it expires 31 May 2005. Does anyone know the status of this?
Furthermore, how well supported are IRIs by other apps?
One problem i see with IRIs is that they still mandate escaping of
characters like "<", ">", '"', Space, "{", "}", "|", "\", "^", and "`".
Especially the Space part might be unexpected by users. Although we can
allow input of these and auto-escape.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's a hate-fuelled gay dog-catcher who hides his scarred face behind a mask.
She's a bloodthirsty belly-dancing bodyguard in the witness protection
program. They fight crime!
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Thu, 2006-09-21 at 11:26 -0400, Dimi Paun wrote: > Complicated URIs like FTP need graphical support to be usable > by mortals (we have server, port, login, password, encoding, > directory, filename). How about we have the backend register > some sort of edit dialog that can present all this information > graphically rather than (just) a textual encoding? If we didn't have a text entry for the location dialog there wouldn't be a problem at all. A desktop can work fine with using things like path bars in browser mode, spatial mode, the entry-less fileselector, connect to server (which is what you describe above) etc. However, people demand a text-entry for filenames, that is just a fact of life we can't get away from. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a fiendish pirate librarian on a search for his missing sister. She's a cold-hearted junkie nun with someone else's memories. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
Hi list On Thu, 2006-09-21 at 11:26 -0400, Dimi Paun wrote: > On Thu, September 21, 2006 10:47 am, Alexander Larsson wrote: > > One solution would be to use some other prefix than / for > > non-local files, and to use some form of escaping only for non-utf8 > > chars and non-printables. This works since we only handle absolute > > pathnames, so anything not starting with / is out of band. > > I think this is a sippery slope -- a new form of URI which is > the same but a bit different will be very confusing. I took the > general population 10 years to grok a tiny bit of the URI concept, > and most people still don't get it. The techinical points about > escaping and so on are so foreign to most folks that they will > be utterly confused (and very annoyed) that they can't enter > an unescaped URI. > > I agree that the fully escaped URI is insane for an interface > with the user. That's clearly just an internal notation. Howerver, > for folks that understand URI enough to type them directly in > text (which is very seldom even for people that do understand > them simply because they are usually long enough that typos are > very likely), we can just simply accept improper URIs unescaped > and escape them internally ourselves. Whatever we do, this is not > really a use case that's common, no need to optimize for it. IRI's can be used for this. IRIs are directly mapped to URIs by escaping. > > Complicated URIs like FTP need graphical support to be usable > by mortals (we have server, port, login, password, encoding, > directory, filename). How about we have the backend register > some sort of edit dialog that can present all this information > graphically rather than (just) a textual encoding? > -- Alex Jones <[EMAIL PROTECTED]> ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Thu, September 21, 2006 10:47 am, Alexander Larsson wrote: > One solution would be to use some other prefix than / for > non-local files, and to use some form of escaping only for non-utf8 > chars and non-printables. This works since we only handle absolute > pathnames, so anything not starting with / is out of band. I think this is a sippery slope -- a new form of URI which is the same but a bit different will be very confusing. I took the general population 10 years to grok a tiny bit of the URI concept, and most people still don't get it. The techinical points about escaping and so on are so foreign to most folks that they will be utterly confused (and very annoyed) that they can't enter an unescaped URI. I agree that the fully escaped URI is insane for an interface with the user. That's clearly just an internal notation. Howerver, for folks that understand URI enough to type them directly in text (which is very seldom even for people that do understand them simply because they are usually long enough that typos are very likely), we can just simply accept improper URIs unescaped and escape them internally ourselves. Whatever we do, this is not really a use case that's common, no need to optimize for it. Complicated URIs like FTP need graphical support to be usable by mortals (we have server, port, login, password, encoding, directory, filename). How about we have the backend register some sort of edit dialog that can present all this information graphically rather than (just) a textual encoding? -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc. ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 14:54 +0200, Alexander Larsson wrote: > Thinking more closely on this it seems that neither plain paths or URIs > are really good enough. For instance, even local filenames need some > sort of escaping for us to be able to display them, since they might > contain binary data (everything but zero and slash is allowed), and we > really want to display e.g. korean smb uris with readable text instead > of crazy escape codes. > > I'll try to think some more on this. Hopefully we can come up with a > good solution. I've looked into this a bit more. Lets start by some examples of filenames of various types: Local filenames (in utf8 mode) 1) standard: /etc/passwd 2) utf8 and spaces: "/tmp/a åäö.txt" (encoding==utf8) 3) latin-1 and spaces: "/tmp/a åäö.txt" (encoding==iso8859-1) 4) filename without encoding: "/tmp/bad:\001\010\011\012\013" (as a C string) 5) mountpoint: /mnt/cdrom (cd has title "CD Title") Ftp mount to ftp.gnome.org [where filenames are stored as utf8, this is detected by using ftp protocol extensions (there is an rfc) or by having the user specify the encoding at mount time] 6) normal dir: /pub/sources 7) valid utf8 name: /dir/a file öää.txt 8) latin-1 name: /dir/a file öää.txt Ftp mount to ftp.gnome.org (with filenames in latin-1) 9) latin-1 name: /dir/a file öää.txt Backend that stores display name separate from real name. [Examples could be a flickr backend, a file backend that handles desktop files, or a virtual location like computer:// (which is implemented using virtual desktop files atm).] 10) /tmp/foo.desktop (with Name[en]="Display Name") To complement this, here are the places where display filenames (i.e utf-8 strings) are used in the desktop: A) Absolute filename, for editing (nautilus text entry, file selector entry) B) Semi-Absolute filename, for display (nautilus window title) C) Relative file name, for display (in nautilus/file selector icon/list view) D) Relative file name, for editing (rename in nautilus) E) Relative file name, for creating absolute name (filename completion for A). This needs to know the exact form of the parent (i.e. it differs for filename vs uri). I won't list this in the table below as its always the same as A from the last slash to the end. Using the current gnome-vfs uri method, this is how the various names would look: A B C D 1) file:///etc/passwdpasswd passwdpasswd 2) file:///tmp/a%20%C3%B6%C3%A4%C3%A4.txta åäö.txt a åäö.txt a åäö.txt 3) file:///tmp/a%20%E5%E4%F6.txt a ???.txt a ???.txt (invalid unicode) a ???.txt 4) file:///tmp/bad%3A%01%08%09%0A%0B bad:? bad:? (invalid unicode) bad:? 5) file:///mnt/cdrom CD Title (cdrom) CD Title (cdrom) CD Title 6) ftp://ftp.gnome.org/pub/sources sources on ftp.gnome.org sources sources 7) ftp://ftp.gnome.org/dir/a%20%C3%B6%C3%A4%C3%A4.txta åäö.txt on ftp.gnome.orga åäö.txt a åäö.txt 8) ftp://ftp.gnome.org/dir/a%20%E5%E4%F6.txt a ???.txt on ftp.gnome.orga ???.txt (invalid unicode) a ???.txt 9) ftp://ftp.gnome.org/dir/a%20%E5%E4%F6.txt a åäö.txt on ftp.gnome.orga åäö.txt a åäö.txt 10)file:///tmp/foo.desktop Display Name Display Name Display Name The stuff in column A is pretty insane. It works fine as an identifier for the computer to use, but nobody would want to have to type that in or look at that all the time. That is why Nautilus also allows entering some filenames as absolute unix pathnames, although not all filenames can be specified this way. If this is used whenever possible column A looks like this: A 1) /etc/passwd 2) /tmp/a åäö.txt 3) file:///tmp/a%20%E5%E4%F6.txt 4) file:///tmp/bad%3A%01%08%09%0A%0B 5) /mnt/cdrom 6) ftp://ftp.gnome.org/pub/sources 7) ftp://ftp.gnome.org/dir/a%20%C3%B6%C3%A4%C3%A4.txt 8) ftp://ftp.gnome.org/dir/a%20%E5%E4%F6.txt 9) ftp://ftp.gnome.org/dir/a%20%E5%E4%F6.txt 10)/tmp/foo.desktop As we see this helps for most normal local paths, but it becomes problematic when the filenames are in the wrong encoding. For non-local files it doesn't help at all. We still have to look at these horrible escapes, even when we know the encoding of the filename. The examples 7-9 in this version shows the problem with URIs. Suppose we allowed an invalid URI like "ftp://ftp.gnome.org/dir/a åäö.txt" (utf8-encoded string). Given the state inherent in the mountpoint we know what encoding is used for the ftp server, so if someo
Re: Streams API [Was: Re: Plans for gnome-vfs replacement]
On Thu, 2006-09-21 at 02:25 -0400, Hans Petter Jansson wrote: > On Wed, 2006-09-20 at 10:07 +0200, Alexander Larsson wrote: > > On Tue, 2006-09-19 at 16:24 -0400, Hans Petter Jansson wrote: > > > > Of course, not all applications need such functionality, but that's > > > just a matter of wrapping this in a higher-level, more rigid API. > > > In my reading of code using gnome-vfs i haven't seen a single use of > > anything like this. Could you perhaps describe some real-life examples > > of how/where this would be used? > > Well, a peer-to-peer filesharing application is the most extreme example > I can think of. Such programs typically need encryption, rate control, > ad-hoc protocol implementations, lots of TCP and UDP sockets and in > decentralized networks, routing facilities. Now, we don't need to > provide all of this, especially not in glib, but having the basic > building blocks there would be nice. > > Another example is instant messaging applications, which require > encryption (typically an SSL layer), rate control (so pasted text can be > sent slowly, lest you trigger the server's anti-flood filter) and ad-hoc > protocols. In fact, I think Gaim is a good example of how the platform's > lack of a good, low-level async I/O API leads to broken applications: > > Gaim (at least version 1.5, which I inspected) has UI that blocks on > network I/O, poor error handling and convoluted protocol code. It also > features an interesting approach to "async" DNS lookups: Fork a child > process and do lookups there, using pipes to communicate with it. > Unfortunately, pipe communication was done using blocking posix calls, > so the end result was a main process that could still block on DNS > lookups. It still strikes me as very specialized code that is not really useful for anywhere near the majority of applications. > It's possible that we're talking past each other here, by the way. I was > thinking of the streams API as lower-level than VFS, so not something > you'd see a need for perusing gnome-vfs consumers. > > My mental image is: > > [posix] <- [Async I/O] <- [Streams] <- [VFS] This is not quite how I see it. The VFS is a module that implements and hands out streams, so if anything streams are above the vfs. Normal local file streams will use blocking posix calls for blocking i/o, and a simple threadpool to implement async calls (or posix aio if supported). For a non-local file the stream would be a socket connection to the vfs daemon for that particular mountpoint. Such a stream will use a simple protocol (dbus, or a custom one) that just sends packages and waits for the reply by blocking or by using the mainloop. Nowhere is there any need for a special async i/o system. You might be thinking of the implementation of the backends though. Here things are a bit more complicated as we must implement the actual protocols. Each backend will be different, because they'll be using various existing libraries having special requirements. Perhaps some could use some general framework. Although it seems to work fine in gnome-vfs without it, as the stuff being implemented is really pretty simple. > > > Also, what's your thinking on supporting asynchronous DNS lookups, > > > representing IP addresses, TCP/UDP sockets, etc? We currently don't > > > have any clear platform solution for that. > > > These are interesting questions, and some applications would surely > > benefit from such code (although others will consider it bloat). I don't > > want to intermix these questions with the vfs layer though. They are not > > really strongly related, only TCP sockets are slightly related to > > streams, and not really in a very interesting way (its just another > > possible stream implementation). > > If you're going to keep implementations of network protocols in glib > (which I assume you'd have to for some VFS modules), you'll have to > implement this anyway. Why not make it available to applications? > > I'm making the assumption that you'll keep VFS modules in glib because > you mentioned it would have "odd dependencies" earlier. I specifically talked about "odd dependencies" as a reason for not having it in glib. ATM I think its better to have the actual vfs implementation outside of glib, and just the vfs daemon protocol implementation in glib. However, nothing is set in stone yet. Its true that some of the backend implementations might have uses for some of these things. And, if we manage to create high quality APIs and implementations of these they might fit in glib. That is a separate discussion for each such implementation IMHO, and up to the glib maintainers. I'm somewhat scared by this from exposing to much of the stuff gnome-vfs needed internally as public APIs, and later having problems maintaining them due to stability guarantees and just bad initial decisions. Anyway, I see no particular need for such things to be in glib to allow the implementation of the vfs, but if they are there they coul
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 10:41 -0500, Federico Mena Quintero wrote: > 2. "Will a stat() or open() be slow on this file?". This works > reasonably well. The only problem is that file-method.c implements it > as a blacklist of known-to-be-remote file systems, *not* as a whitelist > of known-to-be-local ones. So occasionally we get bug reports like "I > have a foofs mount which is slow", where foofs is an obscure network > file system like Novell's novfs. No, the problem is that is causes a slow blocking system call, which is not expected by callers of this function, causing slowdowns. > A bigger problem is that is_local() blocks very badly if you run it on a > file which is on a stale NFS mount, because it stat()s the file directly > to get at its st_dev and such. I *think* this could be better > implemented by stat()ing each component from the root down to the actual > file, and stopping whenever we get to a directory which is a nonlocal > mount. [Of course, stat()ing recursively sucks, but what can you do.] That isn't good enough. It would think "/mnt/nfs/symlink_to_non_nfs/file.txt" is on an NFS share. Its also gonna make this functions even slower. Sure, its a useful feature, if it was called complicated_slow_estimate_of_filesystem_performance(). The problem is really that the name causes people to not be understand what it really does. (i.e. they expect it to do a prefix match) > This problem about blocking on stale mounts shows up in the file > chooser. We do is_local() on each bookmark to see whether to show it or > not, depending on whether the file chooser is configured to show > local-only files. If you have an NFS bookmark and the mount is stale, > it hangs. Is this right behaviour though? Do you expect locally mounted nfs shares (possibly your homedir) to go away if you want to show only "local files". I'd assume that would mean only other gnome-vfs shares. > Also, the calling code could be smarter about not running is_local() for > every single file... maybe we can assume that if a directory is local, > then every file under it is also local (but not subdirectories, which > may be mounts). Nautilus already does this, fortunately, or things would be really slow. nautilus_file_is_local() chains to the NautilusDirectory the file is in and looks at that (cached) value. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a fast talking voodoo romance novelist looking for 'the Big One.' She's a time-travelling French-Canadian politician with an evil twin sister. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Streams API [Was: Re: Plans for gnome-vfs replacement]
On Wed, 2006-09-20 at 10:07 +0200, Alexander Larsson wrote: > On Tue, 2006-09-19 at 16:24 -0400, Hans Petter Jansson wrote: > > Of course, not all applications need such functionality, but that's > > just a matter of wrapping this in a higher-level, more rigid API. > In my reading of code using gnome-vfs i haven't seen a single use of > anything like this. Could you perhaps describe some real-life examples > of how/where this would be used? Well, a peer-to-peer filesharing application is the most extreme example I can think of. Such programs typically need encryption, rate control, ad-hoc protocol implementations, lots of TCP and UDP sockets and in decentralized networks, routing facilities. Now, we don't need to provide all of this, especially not in glib, but having the basic building blocks there would be nice. Another example is instant messaging applications, which require encryption (typically an SSL layer), rate control (so pasted text can be sent slowly, lest you trigger the server's anti-flood filter) and ad-hoc protocols. In fact, I think Gaim is a good example of how the platform's lack of a good, low-level async I/O API leads to broken applications: Gaim (at least version 1.5, which I inspected) has UI that blocks on network I/O, poor error handling and convoluted protocol code. It also features an interesting approach to "async" DNS lookups: Fork a child process and do lookups there, using pipes to communicate with it. Unfortunately, pipe communication was done using blocking posix calls, so the end result was a main process that could still block on DNS lookups. Also, Evolution could use it. It's possible that we're talking past each other here, by the way. I was thinking of the streams API as lower-level than VFS, so not something you'd see a need for perusing gnome-vfs consumers. My mental image is: [posix] <- [Async I/O] <- [Streams] <- [VFS] > >From just reading your post, without deeper insight into what you mean I > would be hesitant to add something like that to glib. Its not clear that > applications need it, and its not clear the the solution we create is > good enough for the applications that need something like it (in fact, I > think its likely that such apps want to do their own thing). > > [...] I wasn't proposing it specifically for glib, at least not the element-based stream model. I thought that was still up in the air. I think we can revisit this later, as the next part is more important to me anyway: > > Also, what's your thinking on supporting asynchronous DNS lookups, > > representing IP addresses, TCP/UDP sockets, etc? We currently don't > > have any clear platform solution for that. > These are interesting questions, and some applications would surely > benefit from such code (although others will consider it bloat). I don't > want to intermix these questions with the vfs layer though. They are not > really strongly related, only TCP sockets are slightly related to > streams, and not really in a very interesting way (its just another > possible stream implementation). If you're going to keep implementations of network protocols in glib (which I assume you'd have to for some VFS modules), you'll have to implement this anyway. Why not make it available to applications? I'm making the assumption that you'll keep VFS modules in glib because you mentioned it would have "odd dependencies" earlier. -- Hans Petter "...you cut a piece, and as you're taking it off of the fork the main piece of the filet may be floating up out of the plate, but you stab it with your fork and put it back down in, and if you do it carefully, the surface tension of the gravy will keep it in place." - Russell Schweickart ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, September 20, 2006 11:41 am, Federico Mena Quintero wrote: > Also, the calling code could be smarter about not running is_local() for > every single file... maybe we can assume that if a directory is local, > then every file under it is also local (but not subdirectories, which > may be mounts). I'd say it's important for that to happen, otherwise we do a stat() to figure out if stat() is slow so we avoid it... -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc. ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 14:54 +0200, Alexander Larsson wrote:
> > s/TRUE/FALSE/, I think. (gnome_vfs_uri_is_local() used to say that NFS
> > filesystems were local, now it says they're not.) Are you suggesting
> > that this behavior is going to go away? It's useful in places as a
> > heuristic, even if it's not 100% reliable. (Although obviously it's only
> > useful if it's guaranteed to not hang.)
>
> Oh, yeah FALSE. I'm not really suggesting anything in particular here.
> Just describing a problem. Its true that there are cases where you want
> to know whethe a file is network mounted or not, but almost all cases
> that were using gnome_vfs_uri_is_local() meant it to check for a
> file:/// uri. The fact that it changed behaviour meant a lot of places
> suddenly broke on NFS shares, and were made a lot slower (since it
> suddenly is a call that does i/o). I've personally changed a lot of code
> to do a g_str_has_prefix("file://") in lots of places.
Both Nautilus and the file chooser seem to use is_local() for just two
things:
1. "If I strip the method prefix, can I feed the filename to POSIX
calls?". This problem goes nicely away when we switch to FUSE.
2. "Will a stat() or open() be slow on this file?". This works
reasonably well. The only problem is that file-method.c implements it
as a blacklist of known-to-be-remote file systems, *not* as a whitelist
of known-to-be-local ones. So occasionally we get bug reports like "I
have a foofs mount which is slow", where foofs is an obscure network
file system like Novell's novfs.
A bigger problem is that is_local() blocks very badly if you run it on a
file which is on a stale NFS mount, because it stat()s the file directly
to get at its st_dev and such. I *think* this could be better
implemented by stat()ing each component from the root down to the actual
file, and stopping whenever we get to a directory which is a nonlocal
mount. [Of course, stat()ing recursively sucks, but what can you do.]
This problem about blocking on stale mounts shows up in the file
chooser. We do is_local() on each bookmark to see whether to show it or
not, depending on whether the file chooser is configured to show
local-only files. If you have an NFS bookmark and the mount is stale,
it hangs.
Also, the calling code could be smarter about not running is_local() for
every single file... maybe we can assume that if a directory is local,
then every file under it is also local (but not subdirectories, which
may be mounts).
Federico
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 15:43 +0200, Paolo Maggi wrote: > Hi, > > > > > > > I was talking with Paolo about this and we were a bit concerned about > > > the above paragraph... How it would work for the case where I simply > > > want to drag an URI from firefox to gedit to open the file[1]? > > > > We could have an api that lets you map a URI into a vfs object with a > > more complicated API that lets the application have a dialog with the > > user requesting things like authentication and prefered filename > > encoding for the share (essentially a mount operation based on a uri). > > We would need to use something like that anyway in the file selector, > > because it would need to be able to mount things as you input locations. > > It is not clear to me what do you mean with "mount operation based on a > uri". Which is the semantic of such operation? > > Suppose you want to open a single file on a web server. > Is the mounting operation the creation of a HTTP session with the web > server? Or what? HTTP is a little trickier than most. If it was an ftp uri then the mount operation would be about creating a session to the ftp server, picking username (if that was not supplied), entering a password, negotiating filename encodings, etc. This would then be part of the global state for that mount, and further i/o operations could just happen, without any complications. Now, http is a stateless protocol, so it doesn't have anything like this. Furthermore, the part of a http uri protected by a password is not visible from the URI, as part of a server can be password protected. This makes things trickier. I would say that mounting say a dav share would consist of specifying the "root uri", connecting to that, verifying it exists and that we can handle any password requests for it would be enough. However, just downloading a single file with http, on a server that might not even support dav. I'm not sure exactly how to do that with a stateful model. However you do it there is likely gonna be some boundary case that bites you. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an unconventional vegetarian cop with nothing left to lose. She's a cosmopolitan streetsmart magician's assistant in the wrong place at the wrong time. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 15:32 +0200, Paolo Maggi wrote: > Hi, > > > Now, these are not quite posix operation, but they are not totally > > unlike it either. I'm not sure how this could be harder to map to ftp or > > http than posix? > > It will not be harder, but we will probably have the same problems we > had with the old gnome-vfs modules to implement the "backends" for HTTP > and FTP. I mean you cannot partially read a file or partially write it > using HTTP (see the "close" problem with HTTP module you described in > your mail). I'm not sure what you mean by "partially write" of a file. Say you call the create() method, then you write to the stream, and then you close it. How could this be partial? The close marks the end of the file data. As to partial reads. The only way to get that with the api I proposed would be to close the input stream before you get to EOF. This isn't all that hard to handle for http, just drop the connection. > So, the question is: do we really need a low-level API to read/write > files? Do you see real use cases where applications using VFS want to > partially read/write files (also considering that the real behavior will > be dependent on the backend implementation)? Partial reads will be needed for mime sniffing, other partial ops are not possible. Maybe you could explain what sort of API you would think not to be "low-level". I don't think i really get it. > I like the Havoc's idea about a using DAV as a model for a VFS API. My proposal is very similar to DAV. DAV certainly is a streaming model (although over a tcp stream, not an abstract stream) with separate put and get methods like in my proposal, and the PROPFIND model havoc talked about is exactly like the proposed readdir replacement. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a lounge-singing overambitious paranormal investigator with a robot buddy named Sparky. She's a sharp-shooting red-headed politician with someone else's memories. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Mandatory Access Control was Re: Plans for gnome-vfs replacement
David Malcolm wrote: > [adding sgrubb, dwalsh and walters to CC] > > On Mon, 2006-09-18 at 18:12 +0200, Alexander Larsson wrote: > > [snip intro paragraph] > > >> So, I think the time has come for a serious look at what gnome-vfs >> could be. I've spent much time last week thinking about the weaknesses >> and problems of the current gnome-vfs and possibilities inherent in a >> redesign, both having learnt from 7 years of gnome-vfs existance and >> the improvements in the platform (both Gnome and surrounding >> technologies) since 1999 when it was designed. >> > > [snip list of problems with existing approach] > > >> Having a global stateful model means all non-local vfs accesses go >> through the vfs daemon. This works pretty well with the smb backend in >> the current gnome-vfs, and smb is the backend most likely to have high >> bandwidth traffic, so this doesn't seem to be a large performance >> problem. Although we do have to take the performance aspect into >> consideration when designing the daemon. >> >> In order to avoid all the problems with threading described above the >> vfs daemon will not use threads. In fact, I think the best approach is >> to let each active mountpoint be its own process. That way we get >> robustness (one mount can't crash the others) and simplify the backend >> creation greatly (each backend fully controls its context). It also >> will let us do concurrent access to e.g. two smb shares (like a copy >> from one to the other). We can't really do this atm since the thread >> lock in the smb backend serializes such access. But with two smb >> processes this is not a problem. >> > > Thinking aloud here: I wonder if people using Mandatory Access Control > (SELinux, AppArmor, Trusted Solaris) might want to have an option to > have all file access go through a backend - even local file access. > > I've long wanted to lock down Evolution so that it doesn't have access > rights to local files, so that if someone constructs a 0-day email > exploit that owns your evolution process, the resulting mess (running as > you) isn't allowed access to arbitrary files owned by you. > > If all local file access under direct user control (browsing, opening > and saving "documents") is performed by a dedicated process running as > the user within his/her session, that process can be given broad access > rights to the user's files. > > If this is available we can lock down GNOME apps so they only have the > rights they need. That way, for instance, evolution can be locked down > so that it can only read ~/.evolution and below [1]; adding an > attachment to an email would require the evolution process to ask the > VFS backend process for the content of the file, rather than loading it > directly. > > This doesn't fully close the hole, since the owned app still has the > right to make vfs API calls as before and a hostile payload could work > that way - but it may make some exploits harder. (Maybe there's a way > to implement a trusted filechooser and only allow the app access to > files which the user has selected in the GUI? can this be done without > having the filechooser out-of-process from the main app?) > > [snip discussion of URLs and statefulness] > > A lot of what you want can be done with SELinux, now but controlling what the user can get is the difficult part. A while back we brainstormed on somehow making the chooser a different application and allowing it to hand the file to the calling app.One possibility for SELinux would be to create a copy of the file and label it such that evolution could read the copy, and then send it. Adding the SELinux Internal list for comment. > Hope this helps > Dave > > [1] and its autosave files; we patch Fedora so these are inside > ~/.evolution rather than ~/ for this reason. > > ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
Hi, > > > > I was talking with Paolo about this and we were a bit concerned about > > the above paragraph... How it would work for the case where I simply > > want to drag an URI from firefox to gedit to open the file[1]? > > We could have an api that lets you map a URI into a vfs object with a > more complicated API that lets the application have a dialog with the > user requesting things like authentication and prefered filename > encoding for the share (essentially a mount operation based on a uri). > We would need to use something like that anyway in the file selector, > because it would need to be able to mount things as you input locations. It is not clear to me what do you mean with "mount operation based on a uri". Which is the semantic of such operation? Suppose you want to open a single file on a web server. Is the mounting operation the creation of a HTTP session with the web server? Or what? Thanks, Paolo ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
Hi, > Now, these are not quite posix operation, but they are not totally > unlike it either. I'm not sure how this could be harder to map to ftp or > http than posix? It will not be harder, but we will probably have the same problems we had with the old gnome-vfs modules to implement the "backends" for HTTP and FTP. I mean you cannot partially read a file or partially write it using HTTP (see the "close" problem with HTTP module you described in your mail). So, the question is: do we really need a low-level API to read/write files? Do you see real use cases where applications using VFS want to partially read/write files (also considering that the real behavior will be dependent on the backend implementation)? I like the Havoc's idea about a using DAV as a model for a VFS API. Ciao, Paolo ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 13:31 +0100, Gustavo J. A. M. Carneiro wrote:
> On Qua, 2006-09-20 at 13:52 +0200, Alexander Larsson wrote:
> > On Wed, 2006-09-20 at 12:55 +0200, Mathieu Lacage wrote:
> > > On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
> > >
> > > > Here is my current GInputStream:
> > >
> > > very nice. Comments below.
> > >
> > > >
> > > > struct _GInputStreamClass
> > > > {
> > > > GObjectClass parent_class;
> > > >
> > > > /* Sync ops: */
> > > >
> > >
> > > Do you dislike the idea of moving the GError as a member of the
> > > GInputStream instance ?
> >
> > Its very uncommon, I'm not sure people will expect that. It will also
> > break things from language mappings that handle GErrors in a special way
> > (say, as an exception).
>
> Even from C, it "hides" the error, making programmers less likely to
> correctly realize they need to handle errors. Moreover, having a shared
> GError per object makes it impossible to ever make the API thread-safe.
The GError itself is only needed for "additional" information about what
went wrong. All the calls also have a way to easy check if the operation
worked or not, like a gboolean return or return -1 on error.
However, despite such technicallities I agree with you.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's a genetically engineered vegetarian jungle king searching for his wife's
true killer. She's a foxy mutant barmaid prone to fits of savage, blood-crazed
rage. They fight crime!
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 14:30 +0200, mathieu lacage wrote: > > > > > 2) What is the signature of GDestroyNotify ? > > > > Its already in gtypes.h: > > typedef void(*GDestroyNotify) (gpointer data); > > ah. I forgot about this. Don't you think it might make sense for ease of > use to add a void *buffer arg and a GOutputStream * arg to the destroy > notification ? Nah, In typical real world cases these would already be in the user_data object. Say if you're reading a whole file async. It feels better to keep to the standard glib destroy notifier handling. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a maverick devious Green Beret on the edge. She's an enchanted streetsmart doctor on the trail of a serial killer. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Qua, 2006-09-20 at 13:52 +0200, Alexander Larsson wrote:
> On Wed, 2006-09-20 at 12:55 +0200, Mathieu Lacage wrote:
> > On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
> >
> > > Here is my current GInputStream:
> >
> > very nice. Comments below.
> >
> > >
> > > struct _GInputStreamClass
> > > {
> > > GObjectClass parent_class;
> > >
> > > /* Sync ops: */
> > >
> >
> > Do you dislike the idea of moving the GError as a member of the
> > GInputStream instance ?
>
> Its very uncommon, I'm not sure people will expect that. It will also
> break things from language mappings that handle GErrors in a special way
> (say, as an exception).
Even from C, it "hides" the error, making programmers less likely to
correctly realize they need to handle errors. Moreover, having a shared
GError per object makes it impossible to ever make the API thread-safe.
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 13:52 +0200, Alexander Larsson wrote: > > 1) Don't you think it might make sense to also add an io priority arg to > > the sync functions ? > > Possibly. It wouldn't really be implementable for normal local files, > but could help for e.g. vfs streams from the daemon. It seems much more > useful for async operations though, since its generally only when you > use those that you get multiple outstanding operations at the same time. agreed. I was merely wondering. > > > 2) What is the signature of GDestroyNotify ? > > Its already in gtypes.h: > typedef void(*GDestroyNotify) (gpointer data); ah. I forgot about this. Don't you think it might make sense for ease of use to add a void *buffer arg and a GOutputStream * arg to the destroy notification ? > Parallel opens for write of a file have implementation defined > behaviour. (Things will depend a lot on the exact timing.) > > What I mean by async opens is that if I open a non-existing file for > reading, the open will succeed, giving me a input stream that will cause > a no-such-file error when you start reading from it. The alternative > would be that the open call blocks, doing i/o to see if the open > succeeds. That would be bad if you were opening the file for async use. > If you do async read on the new input stream the first async read will > also implicitly do an async open. My gut feeling is that moving error reporting for the open call to the read call is wrong but I have not been able to come up with an interesting counter-example. > As to barriers and stuff, I've taken the simple route. Once a stream is > created you can only have one outstanding request (be it sync or async), > and any other operation during this time will return > G_VFS_ERROR_PENDING. Many streams (take a ftp put for instance) just > doesn't support multiple requests. I see. So it would be up to the application developer to create his own queue of requests. thank you for your detailed answer, Mathieu ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
> On Wed, 2006-09-20 at 12:55 +0200, Mathieu Lacage wrote: >> On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote: >> Do you dislike the idea of moving the GError as a member of the >> GInputStream instance ? > > Its very uncommon, I'm not sure people will expect that. It will also > break things from language mappings that handle GErrors in a special way > (say, as an exception). It wouldn't be impossible to wrap. We'd just have to check the per-object error after every call, instead of checking an error parameter for every call. We wouldn't be able to use the auto-generation stuff that expects it to be a parameter. For introspected bindings, the introspection data would have to specify that there's a separate error to be checked. Cairo also has a per-object error status which cairomm throws as an exception. I don't know what the advantages/disadvantages are. >> > gssize (* read)(GInputStream *stream, >> >void *buffer, >> >gsize count, >> >GError **error); [snip] Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 12:55 +0200, Mathieu Lacage wrote:
> On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
>
> > Here is my current GInputStream:
>
> very nice. Comments below.
>
> >
> > struct _GInputStreamClass
> > {
> > GObjectClass parent_class;
> >
> > /* Sync ops: */
> >
>
> Do you dislike the idea of moving the GError as a member of the
> GInputStream instance ?
Its very uncommon, I'm not sure people will expect that. It will also
break things from language mappings that handle GErrors in a special way
(say, as an exception).
> > gssize (* read)(GInputStream *stream,
> > void *buffer,
> > gsize count,
> > GError **error);
> > gssize (* skip)(GInputStream *stream,
> > gsize count,
> > GError **error);
> > gboolean (* close) (GInputStream *stream,
> > GError **error);
> >
>
> 1) Don't you think it might make sense to also add an io priority arg to
> the sync functions ?
Possibly. It wouldn't really be implementable for normal local files,
but could help for e.g. vfs streams from the daemon. It seems much more
useful for async operations though, since its generally only when you
use those that you get multiple outstanding operations at the same time.
> 2) What is the signature of GDestroyNotify ?
Its already in gtypes.h:
typedef void(*GDestroyNotify) (gpointer data);
> 3) Do you expect GDestroyNotify to be invoked afer GAsyncReadCallback
> during normal successful reads ?
Yes. And also after unsuccessful reads. Even cancelled reads (with a
cancelled error). The callback will always be called to avoid the tricky
leaks we have in gnome-vfs. Here is the docs for cancel:
/**
* g_input_stream_cancel:
* @stream: A #GInputStream.
* @tag: a value returned from an async request
*
* Tries to cancel an outstanding request for the stream. If it
* succeeds the outstanding request callback will be called with
* %G_VFS_ERROR_CANCELLED.
*
* Generally if a request is cancelled before its callback has been
* called the cancellation will succeed and the callback will only
* be called with %G_VFS_ERROR_CANCELLED. However, if multiple threads
* are in use this cannot be guaranteed, and the cancel may not result
* in a %G_VFS_ERROR_CANCELLED callback.
*
* The asyncronous methods have a default fallback that uses threads to
implement
* asynchronicity, so they are optional for inheriting classes. However, if you
* override one you must override all.
**/
> > For writing a file things are a bit more complex. An example API set
> > could be:
> > GOutputStream *g_file_append_to (GFile *file);
> > GOutputStream *g_file_create(GFile *file);
> > GOutputStream *g_file_replace (GFile *file,
> > time_t mtime_of_old_version, /* optional */
> > char *backup_name /* optional */ );
> >
> > Error handling on open is handled by the stream (to avoid forcing a sync
> > open). The replace operation does the optimal handling of atomic replace
> > and backup for the specific backend.
>
> Are you saying that _append and _create would not be synchronous
> operations ? If so, what happens if I attempt a sync read after an async
> _append and the async _append fails ? Will the sync read fail and report
> the error of the async _append ? Is there a way to schedule an open
> barrier ? that is, be notified upon open completion with the operation
> status ?
I'm not sure what you mean here. Consider a GFile a wrapper for a
filename. Each of the append_to/create/replace calls constitues an open
of the filename plus a number of writes (to the stream). No operation
returns an Input stream, so you can only write (there is no support for
read/write opens, as this is impossible to implement in many cases). The
operations vary in how they treat a possible already existing file with
the specified name. append_to will append the new data at the end,
create will fail if it already exists, and replace will replace the
contents of the existing file, optionally creating a backup or failing
if the file exiting file isn't the same mtime as you expected.
Parallel opens for write of a file have implementation defined
behaviour. (Things will depend a lot on the exact timing.)
What I mean by async opens is that if I open a non-existing file for
reading, the open will succeed, giving me a input stream that will cause
a no-such-file error when you start reading from it. The alternative
would be that the open call blocks, doing i/o to see if the open
succeeds. That would be bad if you were opening the file for async use.
If you do async read on the new input stream the first async read will
also implicitly do an async open.
As to barriers and stuff, I've taken the simple route. Once a stream is
created you can only
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
> Here is my current GInputStream:
very nice. Comments below.
>
> struct _GInputStreamClass
> {
> GObjectClass parent_class;
>
> /* Sync ops: */
>
Do you dislike the idea of moving the GError as a member of the
GInputStream instance ?
> gssize (* read)(GInputStream *stream,
> void *buffer,
> gsize count,
> GError **error);
> gssize (* skip)(GInputStream *stream,
> gsize count,
> GError **error);
> gboolean (* close) (GInputStream *stream,
> GError **error);
>
1) Don't you think it might make sense to also add an io priority arg to
the sync functions ?
2) What is the signature of GDestroyNotify ?
3) Do you expect GDestroyNotify to be invoked afer GAsyncReadCallback
during normal successful reads ?
> /* Async ops: (optional in derived classes) */
> guint(* read_async) (GInputStream *stream,
> void *buffer,
> gsize count,
> int io_priority,
> GMainContext *context,
> GAsyncReadCallback callback,
> gpointerdata,
> GDestroyNotify notify);
> guint(* close_async) (GInputStream *stream,
> GMainContext *context,
> GAsyncCloseCallback callback,
> gpointerdata,
> GDestroyNotify notify);
> void (* cancel) (GInputStream *stream,
> guint tag);
> }
>
> GInputStream objects can optionally also implement the GSeekable
> interface to support seeking and truncating. This is your basic
> syncronous read API with an addition of some async calls. If a derived
> class doesn't implement the async calls the baseclass will emulate them
> using threads (similar to how gnome-vfs works now). GOutputStream is
> similar, without the skip method, but with a flush method added.
>
> These are then used in the vfs to handle document reading. The API for
> reading a file is simple, it would be something like:
> GInputStream *g_file_read(GFile *file);
>
> For writing a file things are a bit more complex. An example API set
> could be:
> GOutputStream *g_file_append_to (GFile *file);
> GOutputStream *g_file_create(GFile *file);
> GOutputStream *g_file_replace (GFile *file,
>time_t mtime_of_old_version, /* optional */
>char *backup_name /* optional */ );
>
> Error handling on open is handled by the stream (to avoid forcing a sync
> open). The replace operation does the optimal handling of atomic replace
> and backup for the specific backend.
Are you saying that _append and _create would not be synchronous
operations ? If so, what happens if I attempt a sync read after an async
_append and the async _append fails ? Will the sync read fail and report
the error of the async _append ? Is there a way to schedule an open
barrier ? that is, be notified upon open completion with the operation
status ?
Mathieu
--
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 10:43 +0200, Paolo Borelli wrote:
> Il giorno lun, 18/09/2006 alle 18.12 +0200, Alexander Larsson ha
> scritto:
> > I'd like to propose using a stateful model, where you have to
> > explicitly initiate a session ("mount" a share) before you can start
> > accessing files. This will give a well specified time when all forms
> > of authentication will happen, when applications expect it and when
> > they can use a more expressive and suitable API for this kind of
> > operation. The actual i/o operations will then never cause any sort of
> > authentication issues, and can thus be purely non-graphical
> > (i.e. glib-only apps can do i/o). I imagine all/most actual mounting
> > of shares will happen in the file manager and the file selector, or at
> > gnome-session startup, so applications don't really need to handle
> > this themselves.
> >
>
> I was talking with Paolo about this and we were a bit concerned about
> the above paragraph... How it would work for the case where I simply
> want to drag an URI from firefox to gedit to open the file[1]?
We could have an api that lets you map a URI into a vfs object with a
more complicated API that lets the application have a dialog with the
user requesting things like authentication and prefered filename
encoding for the share (essentially a mount operation based on a uri).
We would need to use something like that anyway in the file selector,
because it would need to be able to mount things as you input locations.
On the other hand, exposing URIs like that in the API will be tricky for
other implementations of the vfs. For instance, on windows we probably
wouldn't be using the gnome implementation of the vfs, but rather
something using the native vfs, including the built in smb support, etc.
And win32 doesn't use URIs for this.
One approach could be to have backend specific APIs one could use for
this.
How would you like it to work? I can't believe you actually like the
current way this work, with authentication callbacks, etc.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's a hate-fuelled misogynist librarian from the Mississippi delta. She's an
enchanted extravagent angel from beyond the grave. They fight crime!
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 10:52 +0200, Paolo Borelli wrote:
> Ok, at the risk of sounding a bit picky, can you clarify the following:
>
> Il giorno lun, 18/09/2006 alle 18.12 +0200, Alexander Larsson ha
> scritto:
> > I'd like to call "user document files". These are the kind of files
> > you open, save, or download from the internet to look at. Applications
> > that use these would like highlevel operations that match the kind
> > of operations you use on them, like read-entire-file, save-file,
> > copy-file, etc.
> >
>
> but
>
> > I've been doing some initial sketching of the glib API, and I've
> > started by introducing base GInputStream and GOutputStream similar to
> > the stream objects in Java and .Net. These have async i/o support and
> > will make the API for reading and writing files nicer and more
> > modern. There is also a GSeekable interface that streams can
> > optionally implement if they support seeking.
>
>
> So it's not clear to us if you are aiming at a low-level stream-based
> api or at a higher level document based api. Or maybe both, implementing
> the latter on top of the first.
>
> Does a stream based api gives us any substantial improvement over the
> current posix-like approach? I may well be wrong but I fear that mapping
> stream operations to things like ftp or http can lead to similar issues
> to the ones we have now...
I'm not sure exactly what you mean by low level streams vs a document
based api. I think its easier to discuss this by giving code examples.
So, lemme show you some of the APIs I have in mind. Remember that these
APIs are work in progress though.
Here is my current GInputStream:
struct _GInputStreamClass
{
GObjectClass parent_class;
/* Sync ops: */
gssize (* read)(GInputStream *stream,
void *buffer,
gsize count,
GError **error);
gssize (* skip)(GInputStream *stream,
gsize count,
GError **error);
gboolean (* close) (GInputStream *stream,
GError **error);
/* Async ops: (optional in derived classes) */
guint(* read_async) (GInputStream *stream,
void *buffer,
gsize count,
int io_priority,
GMainContext *context,
GAsyncReadCallback callback,
gpointerdata,
GDestroyNotify notify);
guint(* close_async) (GInputStream *stream,
GMainContext *context,
GAsyncCloseCallback callback,
gpointerdata,
GDestroyNotify notify);
void (* cancel) (GInputStream *stream,
guint tag);
}
GInputStream objects can optionally also implement the GSeekable
interface to support seeking and truncating. This is your basic
syncronous read API with an addition of some async calls. If a derived
class doesn't implement the async calls the baseclass will emulate them
using threads (similar to how gnome-vfs works now). GOutputStream is
similar, without the skip method, but with a flush method added.
These are then used in the vfs to handle document reading. The API for
reading a file is simple, it would be something like:
GInputStream *g_file_read(GFile *file);
For writing a file things are a bit more complex. An example API set
could be:
GOutputStream *g_file_append_to (GFile *file);
GOutputStream *g_file_create(GFile *file);
GOutputStream *g_file_replace (GFile *file,
time_t mtime_of_old_version, /* optional */
char *backup_name /* optional */ );
Error handling on open is handled by the stream (to avoid forcing a sync
open). The replace operation does the optimal handling of atomic replace
and backup for the specific backend.
Now, these are not quite posix operation, but they are not totally
unlike it either. I'm not sure how this could be harder to map to ftp or
http than posix? The API is specifically designed to match the
requirements of protocols like these and to avoid the problems that the
posix mapping created (what use would it be otherwise).
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's a sword-wielding umbrella-wielding librarian on the edge. She's a
strong-willed impetuous socialite on her way to prison for a murder she didn't
commit. They fight crime!
___
gnome-vfs-list mailing list
gnome-v
Re: Plans for gnome-vfs replacement
Ok, at the risk of sounding a bit picky, can you clarify the following: Il giorno lun, 18/09/2006 alle 18.12 +0200, Alexander Larsson ha scritto: > I'd like to call "user document files". These are the kind of files > you open, save, or download from the internet to look at. Applications > that use these would like highlevel operations that match the kind > of operations you use on them, like read-entire-file, save-file, > copy-file, etc. > but > I've been doing some initial sketching of the glib API, and I've > started by introducing base GInputStream and GOutputStream similar to > the stream objects in Java and .Net. These have async i/o support and > will make the API for reading and writing files nicer and more > modern. There is also a GSeekable interface that streams can > optionally implement if they support seeking. So it's not clear to us if you are aiming at a low-level stream-based api or at a higher level document based api. Or maybe both, implementing the latter on top of the first. Does a stream based api gives us any substantial improvement over the current posix-like approach? I may well be wrong but I fear that mapping stream operations to things like ftp or http can lead to similar issues to the ones we have now... ciao Paolo ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
Il giorno lun, 18/09/2006 alle 18.12 +0200, Alexander Larsson ha
scritto:
> I'd like to propose using a stateful model, where you have to
> explicitly initiate a session ("mount" a share) before you can start
> accessing files. This will give a well specified time when all forms
> of authentication will happen, when applications expect it and when
> they can use a more expressive and suitable API for this kind of
> operation. The actual i/o operations will then never cause any sort of
> authentication issues, and can thus be purely non-graphical
> (i.e. glib-only apps can do i/o). I imagine all/most actual mounting
> of shares will happen in the file manager and the file selector, or at
> gnome-session startup, so applications don't really need to handle
> this themselves.
>
I was talking with Paolo about this and we were a bit concerned about
the above paragraph... How it would work for the case where I simply
want to drag an URI from firefox to gedit to open the file[1]?
ciao
Paolo
[1]: This doesn't work right now, the uri is pasted in the text view,
however I am pretty sure it's a gedit bug and that it used to work some
time ago...
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 16:24 -0400, Hans Petter Jansson wrote: > > Of course, not all applications need such functionality, but that's > just a matter of wrapping this in a higher-level, more rigid API. In my reading of code using gnome-vfs i haven't seen a single use of anything like this. Could you perhaps describe some real-life examples of how/where this would be used? >From just reading your post, without deeper insight into what you mean I would be hesitant to add something like that to glib. Its not clear that applications need it, and its not clear the the solution we create is good enough for the applications that need something like it (in fact, I think its likely that such apps want to do their own thing). Furthermore, its not a well understood area, and as such I think its a bad idea to try to integrate with the basic platform that has guaranteed stability and high quality requirements. Having it as a library outside glib makes it possible to experiment with and develop the idea. Your comparison to gstreamer makes me especially worried. While the gstreamer model has been approximately the same all the time the exact details have been tweaked and developed over many many years, and its not until quite recently they seem to have got things really right. We cannot afford anything like that in glib. As long as you can get an asynchronous source and sink from the vfs layer I don't see anything that prohibits a library like this outside of glib to use the vfs layer. > Also, what's your thinking on supporting asynchronous DNS lookups, > representing IP addresses, TCP/UDP sockets, etc? We currently don't > have any clear platform solution for that. These are interesting questions, and some applications would surely benefit from such code (although others will consider it bloat). I don't want to intermix these questions with the vfs layer though. They are not really strongly related, only TCP sockets are slightly related to streams, and not really in a very interesting way (its just another possible stream implementation). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a globe-trotting zombie househusband haunted by memories of 'Nam. She's a cold-hearted renegade nun with an incredible destiny. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Mandatory Access Control was Re: Plans for gnome-vfs replacement
[adding sgrubb, dwalsh and walters to CC] On Mon, 2006-09-18 at 18:12 +0200, Alexander Larsson wrote: [snip intro paragraph] > So, I think the time has come for a serious look at what gnome-vfs > could be. I've spent much time last week thinking about the weaknesses > and problems of the current gnome-vfs and possibilities inherent in a > redesign, both having learnt from 7 years of gnome-vfs existance and > the improvements in the platform (both Gnome and surrounding > technologies) since 1999 when it was designed. [snip list of problems with existing approach] > Having a global stateful model means all non-local vfs accesses go > through the vfs daemon. This works pretty well with the smb backend in > the current gnome-vfs, and smb is the backend most likely to have high > bandwidth traffic, so this doesn't seem to be a large performance > problem. Although we do have to take the performance aspect into > consideration when designing the daemon. > > In order to avoid all the problems with threading described above the > vfs daemon will not use threads. In fact, I think the best approach is > to let each active mountpoint be its own process. That way we get > robustness (one mount can't crash the others) and simplify the backend > creation greatly (each backend fully controls its context). It also > will let us do concurrent access to e.g. two smb shares (like a copy > from one to the other). We can't really do this atm since the thread > lock in the smb backend serializes such access. But with two smb > processes this is not a problem. Thinking aloud here: I wonder if people using Mandatory Access Control (SELinux, AppArmor, Trusted Solaris) might want to have an option to have all file access go through a backend - even local file access. I've long wanted to lock down Evolution so that it doesn't have access rights to local files, so that if someone constructs a 0-day email exploit that owns your evolution process, the resulting mess (running as you) isn't allowed access to arbitrary files owned by you. If all local file access under direct user control (browsing, opening and saving "documents") is performed by a dedicated process running as the user within his/her session, that process can be given broad access rights to the user's files. If this is available we can lock down GNOME apps so they only have the rights they need. That way, for instance, evolution can be locked down so that it can only read ~/.evolution and below [1]; adding an attachment to an email would require the evolution process to ask the VFS backend process for the content of the file, rather than loading it directly. This doesn't fully close the hole, since the owned app still has the right to make vfs API calls as before and a hostile payload could work that way - but it may make some exploits harder. (Maybe there's a way to implement a trusted filechooser and only allow the app access to files which the user has selected in the GUI? can this be done without having the filechooser out-of-process from the main app?) [snip discussion of URLs and statefulness] Hope this helps Dave [1] and its autosave files; we patch Fedora so these are inside ~/.evolution rather than ~/ for this reason. ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
First off, thanks for starting this debate. It looks like gnome-vfs is in for an awesome overhaul. Some comments on streams below. On Mon, 2006-09-18 at 18:12 +0200, Alexander Larsson wrote: > I've been doing some initial sketching of the glib API, and I've > started by introducing base GInputStream and GOutputStream similar to > the stream objects in Java and .Net. These have async i/o support and > will make the API for reading and writing files nicer and more > modern. There is also a GSeekable interface that streams can > optionally implement if they support seeking. We may have a lot to gain from thinking about what we need in the low and intermediate level of the I/O stack now that we're discussing a clean-slate implementation. In addition to VFS, these should facilitate network protocols that don't map to file system operations - for instance, protocols for instant messaging, collaboration and games. Due to the need for asynchronous - and often multiple levels of - tokenization and events, this type of application quickly becomes a mess of callbacks into a complicated state machine. I'm thinking an element-based approach on the low-level end, similar to but simpler than GStreamer's, might alleviate this problem. It would make complicated stream code clearer and more reusable because there's an agreed-upon way to split tasks into multiple state machines (encryption, compression, flow rate limitation, tokenization, parsing, etc). You could also easily insert a "debug element" into a stream to divert an ASCII dump to a second stream for inspection - much nicer than lacing a monolithic I/O loop with g_print()s. Tokens and events could be represented by GObjects inlined in the stream. Of course, not all applications need such functionality, but that's just a matter of wrapping this in a higher-level, more rigid API. Also, what's your thinking on supporting asynchronous DNS lookups, representing IP addresses, TCP/UDP sockets, etc? We currently don't have any clear platform solution for that. -- Hans Petter "...you cut a piece, and as you're taking it off of the fork the main piece of the filet may be floating up out of the plate, but you stab it with your fork and put it back down in, and if you do it carefully, the surface tension of the gravy will keep it in place." - Russell Schweickart ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
Alexander Larsson wrote: > On Mon, 2006-09-18 at 18:23 +, Nate Nielsen wrote: >> Wonderful. This'll allow for things like seeking video to work without >> "Buffering..." on backends that support seek operations. > > Not really. The "Buffering..." part is generally where the app streams > to fill its buffers before starting to play to avoid problems with > network performance. In this case I was referring to when you seek forward in the video player itself, and then the player takes several minutes for the video to "catch up" with your action. Internally the player (multimedia library, whatever) is basically streaming the video in a linear fashion without being able to seek to an arbitrary position in the file. Cheers, Nate ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 16:25 +0200, Xavier Bestel wrote:
> On Tue, 2006-09-19 at 16:17, Alexander Larsson wrote:
> > On Tue, 2006-09-19 at 16:14 +0200, Xavier Bestel wrote:
> > > On Tue, 2006-09-19 at 14:54, Alexander Larsson wrote:
> > > > Lets take a step back and define the requirements we have:
> > > >
> > > > We need to have a form of identifier for files. These come in two forms,
> > > > absolute and relative (e.g. name of a child to a folder). They must be
> > > > persistable (if we save a reference somewhere it must make sense on a
> > > > later login) and transportable (if we pass a reference via e.g. a
> > > > desktop link to another machine or another user it must make some sort
> > > > of sense). The exact contents of such identifiers have no special
> > > > requirements, in fact they could theoretically be binary blobs for all
> > > > users care, but it does seem nice if we could use something as close as
> > > > possible to filenames for local files.
> > >
> > > In that case, would it be possible to have it only be built from
> > > conversion functions and not let applications know what's inside ?
> > > That way "implementation" can change ad-how.
> >
> > I'm not sure what you mean. We can't change the identifier ever, because
> > that would break the persistable requirement.
>
> Oh, yes I forgot.
> What I meant is, if you make the identifier format private, people will
> have less problems with conversions from/to display names.
This is the approach windows shell takes. Their paths are arrays of
{ short data_len; byte data[len] } ended by a double zero.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's a short-sighted coffee-fuelled paramedic who hides his scarred face
behind a mask. She's a pregnant thirtysomething nun with the power to see
death. They fight crime!
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 16:17, Alexander Larsson wrote: > On Tue, 2006-09-19 at 16:14 +0200, Xavier Bestel wrote: > > On Tue, 2006-09-19 at 14:54, Alexander Larsson wrote: > > > Lets take a step back and define the requirements we have: > > > > > > We need to have a form of identifier for files. These come in two forms, > > > absolute and relative (e.g. name of a child to a folder). They must be > > > persistable (if we save a reference somewhere it must make sense on a > > > later login) and transportable (if we pass a reference via e.g. a > > > desktop link to another machine or another user it must make some sort > > > of sense). The exact contents of such identifiers have no special > > > requirements, in fact they could theoretically be binary blobs for all > > > users care, but it does seem nice if we could use something as close as > > > possible to filenames for local files. > > > > In that case, would it be possible to have it only be built from > > conversion functions and not let applications know what's inside ? > > That way "implementation" can change ad-how. > > I'm not sure what you mean. We can't change the identifier ever, because > that would break the persistable requirement. Oh, yes I forgot. What I meant is, if you make the identifier format private, people will have less problems with conversions from/to display names. Xav ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 16:14 +0200, Xavier Bestel wrote: > On Tue, 2006-09-19 at 14:54, Alexander Larsson wrote: > > Lets take a step back and define the requirements we have: > > > > We need to have a form of identifier for files. These come in two forms, > > absolute and relative (e.g. name of a child to a folder). They must be > > persistable (if we save a reference somewhere it must make sense on a > > later login) and transportable (if we pass a reference via e.g. a > > desktop link to another machine or another user it must make some sort > > of sense). The exact contents of such identifiers have no special > > requirements, in fact they could theoretically be binary blobs for all > > users care, but it does seem nice if we could use something as close as > > possible to filenames for local files. > > In that case, would it be possible to have it only be built from > conversion functions and not let applications know what's inside ? > That way "implementation" can change ad-how. I'm not sure what you mean. We can't change the identifier ever, because that would break the persistable requirement. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an unconventional bohemian inventor on the edge. She's a cold-hearted cat-loving advertising executive with only herself to blame. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 14:54, Alexander Larsson wrote: > Lets take a step back and define the requirements we have: > > We need to have a form of identifier for files. These come in two forms, > absolute and relative (e.g. name of a child to a folder). They must be > persistable (if we save a reference somewhere it must make sense on a > later login) and transportable (if we pass a reference via e.g. a > desktop link to another machine or another user it must make some sort > of sense). The exact contents of such identifiers have no special > requirements, in fact they could theoretically be binary blobs for all > users care, but it does seem nice if we could use something as close as > possible to filenames for local files. In that case, would it be possible to have it only be built from conversion functions and not let applications know what's inside ? That way "implementation" can change ad-how. Xav ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 15:04 +0200, Alexander Larsson wrote: > > > > We still need to support URIs too at least in some places, because of > > > > '%u' in .desktop files. If GNOME apps switched to using '%f', then > > > > konqueror (and old versions of GNOME) wouldn't be able to pass remote > > > > files to them any more. Likewise, if nautilus/libgnomedesktop didn't > > > > support using URIs for remote files any more, then they wouldn't be able > > > > to pass remote files to KDE apps. > > > > > > I think URI should still be used to refer to resources "from outside" > > > and to contact the appropriate backends. But internally GFile or > > > GFilePath objects should be used. That is, the user types in an URI, the > > > library resolves the URI to a GFile and passes a serialized form of the > > > GFile to the daemon. > > > > I remember asking in 2000 why gnome-vfs did not use GnomeVFSUri in the > > API rather than raw uris but I cannot remember what the answer was. Does > > anyone know the rationale behind not using a more abstract structure for > > uris in gnome-vfs ? > > It does. In some places, but not in others. In both ways in some places > even! Its just a nightmare... Yes, it is a nightmare. The reason why I ask is that I remember someone explaining the rationale behind using uris always and I seem to remember that at that time, most of the API had only uris rather than GnomeVFSUri. I am growing old :/ Unfortunately, I have lost all of my email archives from before jan 2001. Mathieu -- ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 14:53 +0200, Mathieu Lacage wrote: > hi, > > On Tue, 2006-09-19 at 13:15 +0200, Benedikt Meurer wrote: > > > > We still need to support URIs too at least in some places, because of > > > '%u' in .desktop files. If GNOME apps switched to using '%f', then > > > konqueror (and old versions of GNOME) wouldn't be able to pass remote > > > files to them any more. Likewise, if nautilus/libgnomedesktop didn't > > > support using URIs for remote files any more, then they wouldn't be able > > > to pass remote files to KDE apps. > > > > I think URI should still be used to refer to resources "from outside" > > and to contact the appropriate backends. But internally GFile or > > GFilePath objects should be used. That is, the user types in an URI, the > > library resolves the URI to a GFile and passes a serialized form of the > > GFile to the daemon. > > I remember asking in 2000 why gnome-vfs did not use GnomeVFSUri in the > API rather than raw uris but I cannot remember what the answer was. Does > anyone know the rationale behind not using a more abstract structure for > uris in gnome-vfs ? It does. In some places, but not in others. In both ways in some places even! Its just a nightmare... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a notorious native American dwarf gone bad. She's a sharp-shooting cigar-chomping mercenary who dreams of becoming Elvis. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
hi, On Tue, 2006-09-19 at 13:15 +0200, Benedikt Meurer wrote: > > We still need to support URIs too at least in some places, because of > > '%u' in .desktop files. If GNOME apps switched to using '%f', then > > konqueror (and old versions of GNOME) wouldn't be able to pass remote > > files to them any more. Likewise, if nautilus/libgnomedesktop didn't > > support using URIs for remote files any more, then they wouldn't be able > > to pass remote files to KDE apps. > > I think URI should still be used to refer to resources "from outside" > and to contact the appropriate backends. But internally GFile or > GFilePath objects should be used. That is, the user types in an URI, the > library resolves the URI to a GFile and passes a serialized form of the > GFile to the daemon. I remember asking in 2000 why gnome-vfs did not use GnomeVFSUri in the API rather than raw uris but I cannot remember what the answer was. Does anyone know the rationale behind not using a more abstract structure for uris in gnome-vfs ? The only reason I can imagine would be related to the "round-trip" preserving property. Mathieu -- ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-18 at 23:06 -0400, Dan Winship wrote:
> Cool.
>
> Alexander Larsson wrote:
> > At some point in time gnome_vfs_uri_is_local() started detecting and
> > returning TRUE for NFS mounts and other type of local network
> > mounts. This is both slow and unexpected, and has led to problems and
> > unnecessary changes in many places.
>
> s/TRUE/FALSE/, I think. (gnome_vfs_uri_is_local() used to say that NFS
> filesystems were local, now it says they're not.) Are you suggesting
> that this behavior is going to go away? It's useful in places as a
> heuristic, even if it's not 100% reliable. (Although obviously it's only
> useful if it's guaranteed to not hang.)
Oh, yeah FALSE. I'm not really suggesting anything in particular here.
Just describing a problem. Its true that there are cases where you want
to know whethe a file is network mounted or not, but almost all cases
that were using gnome_vfs_uri_is_local() meant it to check for a
file:/// uri. The fact that it changed behaviour meant a lot of places
suddenly broke on NFS shares, and were made a lot slower (since it
suddenly is a call that does i/o). I've personally changed a lot of code
to do a g_str_has_prefix("file://") in lots of places.
> > As a consequence of the stateful model we don't need the stateless
> > properties that URIs has as identifier. To avoid all the problems
> > comming from the use of URIs we use a much simpler form of
> > identifier. Namely filenames
>
> We still need to support URIs too at least in some places, because of
> '%u' in .desktop files. If GNOME apps switched to using '%f', then
> konqueror (and old versions of GNOME) wouldn't be able to pass remote
> files to them any more. Likewise, if nautilus/libgnomedesktop didn't
> support using URIs for remote files any more, then they wouldn't be able
> to pass remote files to KDE apps.
Clearly we would somehow need to mark the desktop files such that we
know they support the "new vfs", whatever system we use. But using
filenames doesn't make it impossible to pass uris to old gnome apps or
kde apps. In fact, that is one of the strengths of the idea. We just
pass them a "gvfs:///XXX" uri, and then the gvfs implementations in
gnome-vfs and kio automatically makes this work for all old apps.
The usage of %u and %f to mark what types of arguments to pass is
problematic in itself. For example a gnome-vfs app and a kio app both
specify %u, but they can't open the same set of uris. It also doesn't
allow us to mark an app with "only opens local files and http files",
something which is very common with non-gnome/kde apps like say mplayer.
We really need a better way to handle this.
> > I imagine all/most actual mounting
> > of shares will happen in the file manager and the file selector, or at
> > gnome-session startup, so applications don't really need to handle
> > this themselves.
>
> Hm... "Recent files" may be on unmounted shares. Or in the konqueror
> case above, konq would have the remote fs mounted as a kioslave, but
> when it passed the URI to a GNOME app, that app would need to do a gvfs
> mount in order to read the file.
Recent files may be on an unmounted filesystem too. What do we do in
that case? If you open them from the fileselector maybe it can mount
first, same with the panel and nautilus.
Also, the kde URI case above is an example how using URIs automatically
lead you to a stateless model, which we're trying to get out of. I don't
have perfect answers here, but I'm pretty sure that having each i/o
operation able to result in blocking, possibly modal recursive dialogs
is just wrong.
> > For example, we could be to use "//.network/" as a prefix for the vfs
> > filename namespace.
>
> Ew. OK, what's the idea with the fake-paths-instead-of-fake-URIs thing?
> As points against URIs, you say:
>
> 1. Using non-standard ones is evil.
> 2. gnome-vfs uses broken pathname-handling semantics to make things
>easier for applications.
> 3. Escaping and Unescaping is hard, but people want to do it to
>make pretty-looking names.
> 4. It makes people think gnome-vfs is more web-browsery than it
>really is.
>
> But (1) also sorta applies to using things that look like file paths but
> aren't, (2) seems like it ought to be covered by GFile ("This means you
> don't have to do tedious string operations on the pathnames to navigate
> the filesystem."), and (3) seems like it's covered by the display name
> thing ("These filenames would be ... not really presentable to the user
> as is. You'd need to ask for the display name via the vfs to get a user
> readable utf8-encoded string for display.").
>
> Another point in favor of paths over URIs might be "you can share the
> same representation between gvfs-aware and gvfs-naive apps (if you have
> FUSE)", but with the representation you've chosen, you don't even get
> that; you have to use a different path when talking to gvfs-naive apps.
I initially wanted to use $home/.network
Re: Plans for gnome-vfs replacement
Dan Winship wrote: >>As a consequence of the stateful model we don't need the stateless >>properties that URIs has as identifier. To avoid all the problems >>comming from the use of URIs we use a much simpler form of >>identifier. Namely filenames > > We still need to support URIs too at least in some places, because of > '%u' in .desktop files. If GNOME apps switched to using '%f', then > konqueror (and old versions of GNOME) wouldn't be able to pass remote > files to them any more. Likewise, if nautilus/libgnomedesktop didn't > support using URIs for remote files any more, then they wouldn't be able > to pass remote files to KDE apps. I think URI should still be used to refer to resources "from outside" and to contact the appropriate backends. But internally GFile or GFilePath objects should be used. That is, the user types in an URI, the library resolves the URI to a GFile and passes a serialized form of the GFile to the daemon. For example, in the Xfce file manager, we use a path object exactly this way, where an URI like trash:///something-0/file would be resolved to the following path object: path(file) -> path(something-0) -> path(trash root) using refcounting to keep parents only once if possible. Each path object has a parent pointer (which is NULL for the root of an URI scheme), a refcount (excluding the upper bits for the URI scheme) and the name of the path item. Determining the parent path or resolving a relative path is easy then, as you don't need to unescape/escape URIs, but work on path objects with well defined semantics. This way, the possible gvfs would still be compatible with the existing specs (i.e. the thumbnail spec, desktop entry spec, ...), but internally the applications/backends would use the easier to handle path objects and don't need to care about escaping/unescaping of URIs. Not to mention that this would also help to save some memory. Benedikt ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Ter, 2006-09-19 at 09:19 +0200, Alexander Larsson wrote: > On Mon, 2006-09-18 at 18:47 -0300, Johan Dahlin wrote: > > It might be worth mentioning the advantages & disadvantages of including > > this directly in glib (as in cvs module/tarball) instead of separating it. > > > > I'm all for including it in glib itself, but others might disagree, > > especially if it's going to be a big (eg, larger than gobject itself). > > The advantage of shipping it inside glib would be that its "easier to > build", as you don't need to build multiple modules. However, I think > this is a false "easy", as the vfs part will have extensive weird > dependencies on things like samba and neon. This means that it gets very > complicated to build glib if you also want a full vfs. Maybe the way to go would be to have the base VFS core library plus a standard file:// module in glib, but put any extra URI handling modules in another package higher in the stack, installing VFS plugins? -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 11:20 +0100, Gustavo J. A. M. Carneiro wrote: > On Ter, 2006-09-19 at 09:19 +0200, Alexander Larsson wrote: > > On Mon, 2006-09-18 at 18:47 -0300, Johan Dahlin wrote: > > > It might be worth mentioning the advantages & disadvantages of including > > > this directly in glib (as in cvs module/tarball) instead of separating it. > > > > > > I'm all for including it in glib itself, but others might disagree, > > > especially if it's going to be a big (eg, larger than gobject itself). > > > > The advantage of shipping it inside glib would be that its "easier to > > build", as you don't need to build multiple modules. However, I think > > this is a false "easy", as the vfs part will have extensive weird > > dependencies on things like samba and neon. This means that it gets very > > complicated to build glib if you also want a full vfs. > > Maybe the way to go would be to have the base VFS core library plus a > standard file:// module in glib, but put any extra URI handling modules > in another package higher in the stack, installing VFS plugins? Of course we will ship enough code in glib that you get a usable system. That includes reading local files, but perhaps not everything else. This is really a hard requirement, as it is what makes it possible for everyone to use the vfs API to read files and not have any unnecessary dependencies, but yet will be able to access any vfs file when the required modules or whatnot is installed. Exactly how it will work depends on how we handle extension of the vfs. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a witless flyboy vagrant with acid for blood. She's a man-hating cat-loving journalist prone to fits of savage, blood-crazed rage. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Tue, 2006-09-19 at 05:06, Dan Winship wrote:
> > For example, we could be to use "//.network/" as a prefix for the vfs
> > filename namespace.
>
> Ew. OK, what's the idea with the fake-paths-instead-of-fake-URIs thing?
> As points against URIs, you say:
>
> 1. Using non-standard ones is evil.
> 2. gnome-vfs uses broken pathname-handling semantics to make things
>easier for applications.
> 3. Escaping and Unescaping is hard, but people want to do it to
>make pretty-looking names.
> 4. It makes people think gnome-vfs is more web-browsery than it
>really is.
>
> But (1) also sorta applies to using things that look like file paths but
> aren't, (2) seems like it ought to be covered by GFile ("This means you
> don't have to do tedious string operations on the pathnames to navigate
> the filesystem."), and (3) seems like it's covered by the display name
> thing ("These filenames would be ... not really presentable to the user
> as is. You'd need to ask for the display name via the vfs to get a user
> readable utf8-encoded string for display.").
>
> Another point in favor of paths over URIs might be "you can share the
> same representation between gvfs-aware and gvfs-naive apps (if you have
> FUSE)", but with the representation you've chosen, you don't even get
> that; you have to use a different path when talking to gvfs-naive apps.
>
> For points in favor of URIs, there's the fact that KDE uses them,
> various fdo standards use them, and various existing GNOME APIs use them
> (eg, the recent files api mentioned before).
Plus GtkFileSystem does, too.
___
gnome-vfs-list mailing list
gnome-vfs-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-18 at 18:47 -0300, Johan Dahlin wrote: > Very good read, thanks for a great summary. > > Alexander Larsson wrote: > [snip] > > We likely don't want the full gnome/unix vfs implementation in > > glib, instead glib will only ship an implementation of the vfs API for > > local file access, and one that communicates to the vfs > > daemon(s). Then we ship the daemon and the implementations of the > > various backends externally. > > It might be worth mentioning the advantages & disadvantages of including > this directly in glib (as in cvs module/tarball) instead of separating it. > > I'm all for including it in glib itself, but others might disagree, > especially if it's going to be a big (eg, larger than gobject itself). The advantage of shipping it inside glib would be that its "easier to build", as you don't need to build multiple modules. However, I think this is a false "easy", as the vfs part will have extensive weird dependencies on things like samba and neon. This means that it gets very complicated to build glib if you also want a full vfs. Another advantage is that its easier for separate people to maintain the backends outside of glib, and that its easier to upgrade them without having to upgrade glib. > Not sure I completely understand which extension mechanisms that are going > to be used. Will GModule be used to implemented the backends/protocols much > as it is in gnome-vfs today? > > It would be helpful to have a diagram or a document describing the > components of the proposed API so we can get a complete picture of the flow > between application, daemons and applications. Part of the reason things are unclear is that the design is no quite finished yet. I'll continue working on it, and hopefully produce a bit more documentation. > > I've been doing some initial sketching of the glib API, and I've > > started by introducing base GInputStream and GOutputStream similar to > > the stream objects in Java and .Net. These have async i/o support and > > will make the API for reading and writing files nicer and more > > modern. There is also a GSeekable interface that streams can > > optionally implement if they support seeking. > > You're only mentioning the low-level stream parts here, but is there any > previous work of a filesystem/virtual folder API apart from POSIX which > could be used as a comparision? > > Do you know what win32, OS/X, Java, .NET, etc provide in this area? I like the java.io.File class which does the pathname abstraction. Win32 has something called "Shell extensions" which are similar to the whole VFS layer. Other than that there is not a lot of previous art. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a Nobel prize-winning arachnophobic astronaut looking for 'the Big One.' She's a ditzy French-Canadian archaeologist from out of town. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-18 at 18:23 +, Nate Nielsen wrote: > Awesome work Alex... > > Alexander Larsson wrote: > > > > > These filenames would be the real identifier for the files, and as > > such not really presentable to the user as it. You'd need to ask for > > the display name via the vfs to get a user readable utf8-encoded > > string for display. > > Do you see the display names being able to be mapped back to those > identifiers? Or would it be sort of Windowsish where you can't type > certain paths in explorer. As far as the user is concerned they just > sort of start at some magical top level entity. > > For example a lot of people currenty really like the Ctrl-L location box > and the ability to type URIs. If the display names are typeable by the > user, it may be worth trying to have the display names look similar to > the URIs people are used to now... There needs to be a way to map a display name entered by the user for say a new file to be saved to a filename. I don't think we can guarantee a roundtrip though. However, many filenames will be in the form of ascii and utf8, so I think in most cases typing in a filename will work. Maybe we can support a form of escaped text for input of non-utf8? Clearly this needs some thinking. > > I've been doing some initial sketching of the glib API, and I've > > started by introducing base GInputStream and GOutputStream similar to > > the stream objects in Java and .Net. These have async i/o support and > > will make the API for reading and writing files nicer and more > > modern. There is also a GSeekable interface that streams can > > optionally implement if they support seeking. > > Wonderful. This'll allow for things like seeking video to work without > "Buffering..." on backends that support seek operations. Not really. The "Buffering..." part is generally where the app streams to fill its buffers before starting to play to avoid problems with network performance. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a lounge-singing gay househusband haunted by memories of 'Nam. She's a sharp-shooting Bolivian opera singer who believes she is the reincarnation of an ancient Egyptian queen. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
Cool.
Alexander Larsson wrote:
> At some point in time gnome_vfs_uri_is_local() started detecting and
> returning TRUE for NFS mounts and other type of local network
> mounts. This is both slow and unexpected, and has led to problems and
> unnecessary changes in many places.
s/TRUE/FALSE/, I think. (gnome_vfs_uri_is_local() used to say that NFS
filesystems were local, now it says they're not.) Are you suggesting
that this behavior is going to go away? It's useful in places as a
heuristic, even if it's not 100% reliable. (Although obviously it's only
useful if it's guaranteed to not hang.)
> As a consequence of the stateful model we don't need the stateless
> properties that URIs has as identifier. To avoid all the problems
> comming from the use of URIs we use a much simpler form of
> identifier. Namely filenames
We still need to support URIs too at least in some places, because of
'%u' in .desktop files. If GNOME apps switched to using '%f', then
konqueror (and old versions of GNOME) wouldn't be able to pass remote
files to them any more. Likewise, if nautilus/libgnomedesktop didn't
support using URIs for remote files any more, then they wouldn't be able
to pass remote files to KDE apps.
> I imagine all/most actual mounting
> of shares will happen in the file manager and the file selector, or at
> gnome-session startup, so applications don't really need to handle
> this themselves.
Hm... "Recent files" may be on unmounted shares. Or in the konqueror
case above, konq would have the remote fs mounted as a kioslave, but
when it passed the URI to a GNOME app, that app would need to do a gvfs
mount in order to read the file.
> For example, we could be to use "//.network/" as a prefix for the vfs
> filename namespace.
Ew. OK, what's the idea with the fake-paths-instead-of-fake-URIs thing?
As points against URIs, you say:
1. Using non-standard ones is evil.
2. gnome-vfs uses broken pathname-handling semantics to make things
easier for applications.
3. Escaping and Unescaping is hard, but people want to do it to
make pretty-looking names.
4. It makes people think gnome-vfs is more web-browsery than it
really is.
But (1) also sorta applies to using things that look like file paths but
aren't, (2) seems like it ought to be covered by GFile ("This means you
don't have to do tedious string operations on the pathnames to navigate
the filesystem."), and (3) seems like it's covered by the display name
thing ("These filenames would be ... not really presentable to the user
as is. You'd need to ask for the display name via the vfs to get a user
readable utf8-encoded string for display.").
Another point in favor of paths over URIs might be "you can share the
same representation between gvfs-aware and gvfs-naive apps (if you have
FUSE)", but with the representation you've chosen, you don't even get
that; you have to use a different path when talking to gvfs-naive apps.
For points in favor of URIs, there's the fact that KDE uses them,
various fdo standards use them, and various existing GNOME APIs use them
(eg, the recent files api mentioned before).
So are paths really better than URIs? (I'm totally willing to believe
the answer is "yes", I just don't see it yet.)
> The set of operations on files and folders would be both simplified
> and extended. We'd remove complicated things like read+write access to
> a file, and give less posix-like guarantees...
But:
> We will also write a single gnome-vfs backend that allows access to
> all the glib vfs shares by using a uri like gvfs:///XXX that just maps
> to //.network/XXX. We can also implement a similar backend for kio so
> that kde applications can read and write to the shares.
If gvfs deviates too far from POSIX, then it's the http-method problem
all over again; the gnome-vfs/kio/FUSE modules will have to have hacks
to deal with the non-POSIX semantics of the gvfs filesystem. So the
hacks like write-whole-file-on-close still need to exist somewhere,
although at least you'll never hit them if you use the preferred APIs.
> Furthermore, if FUSE is supported on the system we can write a FUSE
> filesystem so that we can access the files as $HOME/.network/XXX.
Rather than having both a vfs daemon and a FUSE daemon, it seems like it
ought to be possible to squish them both into the same process.
"libgvfsbackend" or whatever would link to libfuse, receive the POSIX
requests from the kernel, make the appropriate not-quite-POSIX gvfs
requests of the backend (via local procedure calls, not dbus), and
perform whatever unfortunate hacks were necessary to get POSIX-like
semantics.
Then the gnome-vfs and kio bridges could also use this more POSIXy
interface (presumably via dbus), so that they could get POSIX-like
semantics too without needing to reimplement the kludges.
And actually, for the more filesystem-like backends (smb, etc), we could
just let the backend implement the POSIX interfaces itself, in addition
to the gvfs ones, t
Re: Plans for gnome-vfs replacement
Very good read, thanks for a great summary. Alexander Larsson wrote: [snip] > We likely don't want the full gnome/unix vfs implementation in > glib, instead glib will only ship an implementation of the vfs API for > local file access, and one that communicates to the vfs > daemon(s). Then we ship the daemon and the implementations of the > various backends externally. It might be worth mentioning the advantages & disadvantages of including this directly in glib (as in cvs module/tarball) instead of separating it. I'm all for including it in glib itself, but others might disagree, especially if it's going to be a big (eg, larger than gobject itself). Not sure I completely understand which extension mechanisms that are going to be used. Will GModule be used to implemented the backends/protocols much as it is in gnome-vfs today? It would be helpful to have a diagram or a document describing the components of the proposed API so we can get a complete picture of the flow between application, daemons and applications. > I've been doing some initial sketching of the glib API, and I've > started by introducing base GInputStream and GOutputStream similar to > the stream objects in Java and .Net. These have async i/o support and > will make the API for reading and writing files nicer and more > modern. There is also a GSeekable interface that streams can > optionally implement if they support seeking. You're only mentioning the low-level stream parts here, but is there any previous work of a filesystem/virtual folder API apart from POSIX which could be used as a comparision? Do you know what win32, OS/X, Java, .NET, etc provide in this area? Johan ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
Awesome work Alex... Alexander Larsson wrote: > These filenames would be the real identifier for the files, and as > such not really presentable to the user as it. You'd need to ask for > the display name via the vfs to get a user readable utf8-encoded > string for display. Do you see the display names being able to be mapped back to those identifiers? Or would it be sort of Windowsish where you can't type certain paths in explorer. As far as the user is concerned they just sort of start at some magical top level entity. For example a lot of people currenty really like the Ctrl-L location box and the ability to type URIs. If the display names are typeable by the user, it may be worth trying to have the display names look similar to the URIs people are used to now... > I've been doing some initial sketching of the glib API, and I've > started by introducing base GInputStream and GOutputStream similar to > the stream objects in Java and .Net. These have async i/o support and > will make the API for reading and writing files nicer and more > modern. There is also a GSeekable interface that streams can > optionally implement if they support seeking. Wonderful. This'll allow for things like seeking video to work without "Buffering..." on backends that support seek operations. Cheers, Nate ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-18 at 19:21 +0200, Paolo Borelli wrote: > Il giorno lun, 18/09/2006 alle 18.12 +0200, Alexander Larsson ha > scritto: > > As soon as you spend some time looking at this problem is evident that > > to solve the platform ordering issues we really need a clean cut from > > the current gnome-vfs. I think the ideal level for a VFS would be in > > glib, in a separate library similar to gthread or gobject. > > > > Alex, all of your mail is great and I will read it a couple more times > before making any further comment. > > I just want to ask about one of the other aspects of VFS you didn't > mention and that I happen to care about: mime types. Do you plan to have > a simple wrapper of the xdg-mime api in glib? I'm not sure. In general I'd like mime sniffing to happen in the daemon so that it can be cached between processes, and so that it will involve less roundtrips between the daemon and the app. However, local file access will be implemented fully client-side, so there must be a way to do the mime sniffing in the client. Should this code be exposed, or should it be parts of the internals of a unix-specific local file vfs implementation? I know gedit uses the mime sniffing stuff a lot. However, I'm not sure exposing the freedesktop mime system on windows is a good idea. The windows version of the glib vfs should probably use the windows built in file classes (mapped to some mimetype as needed) so that apps can e.g. use the right filetype -> application mapping build into windows. Tricky stuff... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an uncontrollable Jewish cowboy on a search for his missing sister. She's a mistrustful foul-mouthed angel trying to make a difference in a man's world. They fight crime! ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Re: Plans for gnome-vfs replacement
Il giorno lun, 18/09/2006 alle 18.12 +0200, Alexander Larsson ha scritto: > As soon as you spend some time looking at this problem is evident that > to solve the platform ordering issues we really need a clean cut from > the current gnome-vfs. I think the ideal level for a VFS would be in > glib, in a separate library similar to gthread or gobject. Alex, all of your mail is great and I will read it a couple more times before making any further comment. I just want to ask about one of the other aspects of VFS you didn't mention and that I happen to care about: mime types. Do you plan to have a simple wrapper of the xdg-mime api in glib? ciao Paolo ___ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
