[Open Office] Generic desktop adapter (proposal & prototype)

[nf2]

michael meeks wrote:

>Hi there,
>
>On Thu, 2005-12-01 at 00:39 +0100, nf2 wrote:
>  
>
>>The problem with D-VFS is who's gonna start coding it (I could try, but 
>>i can't afford doing such a huge thing as a hobby project ;-)).
>>    
>>
>
>	Quite.
>
>  
>
>>I have played with that VFS stuff a bit (i tried to write a KIO->Gnome 
>>VFS bridge once - called gvfs-kio), coded a very lightweight IPC library 
>>called TVariant and wrote down my thoughts on that topic...
>>    
>>
>
>	Hmm - D/BUS fills this gap surely, and everything in future will/should
>be linked to it ?
>  
>
Don't know if D-Bus is lowlevel and flexible enough for streaming data 
with the least possible overhead. The simplicity of the kio-slaves IPC 
protocol has charm too...


>	Either way - 1 thing I like about gnome-vfs is that it doens't
>introduce yet-another poorly-performing IPC mechanism between you and
>your 4Gb local-disk data file ;-) 
>  
>
Well. That might only be true for the synchronous (blocking) interface. 
For the async interface i would guess that using thread bridges (like in 
Gnome-VFS) or IPC-sockets (like in KIO-slaves) have similar performance 
cost. IPC sockets might even be faster, cause they have buffers and 
therefore reduce the number of context-switches (When pushing data 
chunks or direntries through one-way).

Generally speaking there are so many aspects in Gnome-VFS and KIO, that 
it's impossible to say which one is better designed.

If i were to design a shared VFS today, it would be a cluster of 
daemons. But not one daemon per client (like in KIO), but rather one per 
resource the VFS connects to (an account on a server, a tar.gz archive,...).

Every daemon would be a kind of "virtual mountpoint", with all the 
session logic inside: passwords, connection pools, session state.

The reason why i wouldn't pack everything into a single daemon is 
stability and garbage-collection. Backends use 3rd party libraries to 
connect to network resources which might be buggy and have memory leaks.

regards,

Norbert