A common VFS and a Common conf-system [Part II]
nf2 at scheinwelt.at
Thu Mar 3 00:39:43 EET 2005
Waldo Bastian wrote:
>On Tuesday 01 March 2005 16:48, Sean Middleditch wrote:
>>My original idea was to *NOT* have the backends run in the library or
>>host app itself, but instead to have a per-user daemon that handled all
>>of the actual VFS work, and then the library would simply be an API that
>>made it easy for an app to talk to the daemon.
>Yes, I think this is a good approach. We may want to put some thought in
>whether we would want to have a single-threaded daemon process, a
>multi-threaded daemon or a single process deamon with additional worker
I think there are only two options:
1) A single multithreaded daemon with threads per VFS connection (like
Gnome-VFS daemon modules). The problem with this is that a buggy VFS
module could crash the whole VFS system.
2) Separate multithreaded daemons for every VFS "session" (like a ftp
user at server combination). Like in the first case every connection would
have it's own thread in the session daemon.
Session data like passwords would then be kept in the "session" daemon
This would require a "registry" daemon to manage the session daemons.
IMO having single threaded "per connection" processes like KIO is
problematic from design, because it makes access synchronization very hard:
Some VFS resources will need access synchronization - editing archives
for instance - or a FTP server which permits only one connection per
user. In this case a "pausing - have to finish another operation"
callback would be nice feedback.
Concering the internal interface for VFS-Modules i would go the
synchronous Gnome-VFS direction with open-read/write-close methods plus
callbacks. VFS modules should be as portable and universal as possible
(like linking them into servers or CLI tools directly without making use
of the Desktop-VFS framework).
But the interface should be "weak typed": Data structures for
"queryInterface()", Directory-Entries and Callbacks should be a bit like
PHP arrays (key-value maps which can also be hierarchical).
This "weak typing" would make it possible to use the same
open/read/write methods to access directories and files (Don't know if
that makes sense). The VFS library could even be used to access the
desktop configuration database - it would be just another VFS module.
Perhaps one should see the Desktop-VFS as an "application server".
For the async frontend i would steal many ideas from KIO. Cause it's
very friendly to application developers and the "home grown" IPC
protocol seems to be quite lean.
More information about the xdg