dvfs api and toolkits

[nf2]

Owen Taylor wrote:

>The point is not that the main loop cannot be recursed, but that
>recursing the main loop when the app isn't expecting it will result
>in hard-to-debug, obscure, bugs. A synchronous API must block with
>no side effects until the call completes.
>
>  
>
There seem to be three "use-cases" a VFS should support:

A) async (non blocking IO)

B) pseudo synchronous, like KIO::NetAccess. Blocks for a complete 
operation (like downloading a file) but keeps the main-loop iterating.

C) real synchronous streaming API (blocking; flow controlled; like 
traditional open-read/write-close; no main-loop!).


KIO supports "A" and "B" at the moment. Gnome-VFS "A" and "C".

"A+B" are important for GUI applications and "B" is a main-loop specific 
convenience API on top of "A".

"C" is interesting for CLI apps and more sophisticated GUI apps or 
libraries, which use background threads for data processing (rendering,...).

For several reasons - which have already been discussed - i would expect 
that D-VFS daemon will use "C" (with threads) internally for the 
backends, and should provide "A","B" and "C" through a socket to the 
clients ("A" and "C" at least).

If you want to write a really portable D-VFS, which can be integrated 
into any toolkit, it might be better to standardize a communication 
protocol for the client->D-VFS daemon connection rather than an API... I 
have started to code a very simple "TinyVariant" library, which could be 
used for such a socket communication (in case D-BUS doesn't fit). I'll 
show you soon...


A) Protocol for async (non blocking) clients:

[client]--[daemon]

  ----get()--->
  <--mime------ (mime type and metadata callback)

  <--data------
  <--data------
  <--progress--
  <--data------
  <--data------
  <--progress--
   ...
  ----cancel-->  (optional cancel)

  <--finished--


B) Protocol for pseudo synchronous clients (download entire file for 
instance):

[client]--[daemon]

  ---getall()->
  <--mime------
  <--progress--
  <--progress--
   ...
  ----cancel-->  (optional cancel)

  <--finished--


C) Wire protocol for real synchronous (blocking) clients. Every function 
call returns an "ack-message" ret().

[client]--[daemon]

  ----open()-->
  <---mime-----  (mime type callback)
  -----ret()-->
  <--ret()-----

  -----read--->
  <--ret(data)-

  -----read--->
  <--ret(data)-

  -----read--->
  <--progress--  (progress callback)
  -ret()------>
  <--ret(data)-

  -----read--->
  <--ret(data)-

  ----close--->
  <--ret()-----



cheers,
norbert