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

[Sean Middleditch]

On Wed, 2005-03-02 at 23:00 +0000, Jamie McCracken wrote:

>If its single threaded then it must be 100% async (otherwise waiting for 
>a slow FTP connection would block other apps trying to access local 
>storage).

Asynchronous is a given.  There is absolutely no question at all about
whether it will or wont be asynchronous - it will be.

>
>An async one would also probably be unfreindly like the current 
>Gnome-vfs thats why I say go for the in process route - we dont need 
>threads or unfriendly async calls everywhere (well we will still need a 
>few of them I suppose so apps dont appear dead while waiting!)

OK, two things.  First off, the *daemon* being asynchronous has
completely no impact on the application being synchronous or not.
Apache is asynchronous, but that doesn't mean that a web browser must
be, right?

Second, even given that, the API will be very heavily focused on
asynchronous behavior, because you don't have a whole lot of choice.
Applications need to remain responsive, handle expose events, allow the
user the cancel the operation, and perhaps do other work in the
background (think of a word processor with two windows open, for
example).

A synchronous API should also be available; I do agree with that.
Synchronous interfaces are easier to use, and non-GUI apps are probably
quite happy using such an interface.  It's also possible to use a GUI
with a synchronous interface similar to how some apps have synchronous
dialog invocations, although those are something that are relatively
frowned upon these days.  This synchronous interface is less important
to the target applications of D-VFS than the asynchronous interface,
however, and that should be kept in mind.

We will do both.  I even noted such in my first mail on the
subject.  ;-)
>
>jamie.
>
-- 
Sean Middleditch <elanthis at awesomeplay.com>