A common VFS and a Common conf-system [Part II]

[Philip Van Hoof]

On Tue, 2005-03-01 at 10:48 -0500, Sean Middleditch wrote:



> == Polling API ==
> 
> That said, the daemon itself should be an implementation detail of the
> library.  Users of the library should not be forced to even consider
> whether there's a daemon doing the real work or not; all they should
> think about is their app.  

In that case it's important that this API will inform the application in
it's mainloop about "changes".

Simple example. In case Nautilus wants to know how much of a
copy-process is done, it shouldn't be a thread who's going to fill in
the GtkProgressBar. Many GUI-tookits who are going to be used with this
VFS are only thread-aware. Not thread-safe.

Many applications who are at this moment using, for example, gnome-vfs,
aren't designed with threading in mind. If the migration from gnome-vfs
to this new system is to hard, it won't be used at all. Not that I'm
saying building a thread-oriented Gtk+ application is impossible or very
hard. But it's harder than not using threads. Many developers will
dislike it when it's suddenly required to gtk_threads_enter() and
gtk_threads_leave() in the callback that is going to give information
about such operations.

So the library will have to put such callbacks as events on the
g_main_loop.. (g_idle_add).

So a glib-binding is necessary? Just like DBUS has one. I guess?

In fact migrating from, for example, gnome-vfs to this new system should
be a matter of search and replace if you really want it to become
widespread and actually used. Else most applications will simply stick
to gnome-vfs for many years to come.



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org