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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
On Seg, 2006-10-02 at 21:03 +0200, Andy Wingo wrote: Hi Alex, On Wed, 2006-09-20 at 13:52 +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). I think most languages have their own customary ways of performing IO that they'd like to get gnome-vfs to map to, and so the gnome-vfs wrappers are custom anyway. (That is at least the case with the guile binding, not sure about others.) That is true for the Python bindings also. But I must emphasize that the main problem of a per-object GError is that it makes it impossible to ever make the API reentrant/thread-safe. Unless we want to narrow the API to single threaded usage right now, let's not go down that path. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 09:16 +0200, 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.
Just a little note: GTypeInterface types really act more as mixins
than real interfaces in GObject, as they can effectively support a
default implementation inside their own definitions.
In fact, if you look at Java and .Net you will see that their streams
are objects too, not interfaces.
This happens mostly because Java and .Net do not have a native concept
of mixin/role types and only have pure interface types; so the only way
they have to define an abstract type with default implementations is to
create an abstract object.
Anyway, there's no hard or compelling reason for using a GTypeInterface
instead of an abstract GObject.
Ciao,
Emmanuele.
--
Emmanuele Bassi, E: [EMAIL PROTECTED]
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 09:16 +0200, 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.
Just a little note: GTypeInterface types really act more as mixins
than real interfaces in GObject, as they can effectively support a
default implementation inside their own definitions.
So this is then a bit like multiple inheritance (of implementations). That
should probably be avoided because it's not possible for some programming
languages to represent it in their wrappers. And because it's difficult.
In fact, if you look at Java and .Net you will see that their streams
are objects too, not interfaces.
This happens mostly because Java and .Net do not have a native concept
of mixin/role types and only have pure interface types; so the only way
they have to define an abstract type with default implementations is to
create an abstract object.
Anyway, there's no hard or compelling reason for using a GTypeInterface
instead of an abstract GObject.
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
On Mon, 25 Sep 2006, Murray Cumming wrote:
On Mon, 2006-09-25 at 09:16 +0200, 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.
Just a little note: GTypeInterface types really act more as mixins
than real interfaces in GObject, as they can effectively support a
default implementation inside their own definitions.
So this is then a bit like multiple inheritance (of implementations). That
should probably be avoided because it's not possible for some programming
languages to represent it in their wrappers. And because it's difficult.
there is no need for programming languages to present this in their
wrappers. it just means that interface implementors can opt to not override
an interface method and still get common default behaviour. if you want to
translate this to C++, it's simply:
virtual base_class_method() {};
instead of
virtual base_class_method() = 0;
Murray Cumming
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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 glib.h
#include glib-object.h
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 glib.h
#include glib-object.h
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
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 could certainly be useful. In fact, they might be useful for the vfs implementation
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 someone types it in we
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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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 have one outstanding request (be it sync or async),
and any other operation
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Mandatory Access Control was Re: Plans for gnome-vfs replacement
David Malcolm [EMAIL PROTECTED] wrote: (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? This is what Plash implements (see http://plash.beasts.org). This kind of file chooser is known as a powerbox, taking the term from CapDesk. can this be done without having the filechooser out-of-process from the main app?) If the application runs in a virtual machine inside the process, using programming language based security, then yes. Otherwise, not really: if there is no boundary between the application and the file chooser, or the application can otherwise supply the filename that is interpreted in the user's namespace, the application can grant itself access to files without the user having to choose them. Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Mandatory Access Control was Re: Plans for gnome-vfs replacement
David Malcolm [EMAIL PROTECTED] wrote: (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? This is what Plash implements (see http://plash.beasts.org). This kind of file chooser is known as a powerbox, taking the term from CapDesk. You would need to combine that with a trusted recently used files service then, I imagine... for applications that want to keep a reference to files opened through the file dialog for later use. Cheers, Waldo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-18 at 18:23 +, Nate Nielsen wrote: Awesome work Alex... Alexander Larsson wrote: snip 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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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 as the prefix for the vfs filenames. However, that is problematic, as such filename refer
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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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. snip of the awesome mail 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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. snip of the awesome mail 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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
Awesome work Alex... Alexander Larsson wrote: snip 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-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, to avoid the need for kludges when
