A common VFS and a Common conf-system [Part II]
lah at micropp.se
Thu Mar 3 03:02:28 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 processes.
Does this at all matter? If I have anderstod corektly:
apps ---D-BUS---- D-VFS deamon ----D-BUS---- Protokoll backend deamon
Wher the the D-VFS demon just keep track of what backend handles what
protokoll, and witch bakend deamons are loaded, wher they are and what
'sites' they have open.
If one app wants to access a file over ftp, say ftp//:foo.bar/somefile
1) it ask the D-VFS deamon for a conektion to ftp//:foo.bar
2a) if the D-VFS know of no ftp demon, one is started (posably by D-BUS
aktivation), and given the request ftp//:foo.bar, the demon responds to
the D-VFS demon that it takes responsabillity of ftp//:foo.bar. D-VFS
save a record of the ftp deamons existans and comitment.
2b) if the D-VFS deamon know a ftp demaon, sends the request to it. The
ftp demon can self deside wheter it shuld handle the conection itself,
in witch case it just reports that back to the D-VFS deamon, or it might
clone itself (by fork or other means) an let onother process report pack
to the D-VFS deamon that it take responsability for ftp//:foo.bar.
2c) if the D-VFS deamon know of a ftp deamon that alredy have foo.bar
open, it just skips to 3.
3) In any case, the D-VFS demon report back to the app what backend
deamon handles ftp//:foo.bar
4) The app then talk thru D-BUS and optinaly other means directly with
the backend deamon.
Wheter ther is one deamon for every ftp conektion, or one fore each
site, is an implementation detail of the backend. If the backend is
threded or not is also an implementation detail of the backend deamon.
Sometimes posably one backend demon cover more then one protokol. In
cases they are simular (like http, https, DAV, different DAV
subprotokoll). Such deamon can still 'fork off' for every different
server and/or protokol it conects to.
The protokoll shuld idealy work well on the whole set of possable
implementations. It is likly that different implementations is ideal for
More information about the xdg