On samedi 7 octobre 2017 21:22:42 CEST Mark Gaiser wrote: > Hi, > > I'm about to experiment a bit with a KIO slave idea [1] I've been having > for a while. > > I get how a KIO slave works, that's not an issue. > > What i don't get fully is how a KIO slave with persistent storage works > (say like baloo or stash) where a KIOD/KDED module is required to read from > the storage. > > How would i make a module that: > * starts on-demand and stays running for the session lifetime once it's > started. It should only stop if the session stops or if i tell it to stop. > I'm guessing this is with "X-KDE-Kded-phase" at 2, but then i still don't > get where that module is registered, how kded knows about it and - most > importantly! - what needs to be done to get KDED or KIOD to start it? Is > that some sort of spacial dbus signal?...
KDED/KIOD modules are plugins (.so with embedded json, installed in the right dir for kiod to find it). Take one example (for kiod: kio/src/kssld; for kded: kio/src/ioslaves/remote/ kdedmodule), do the same :) > * We have KDED and KIOD, i think i would like to use KIOD for the reduced > dependency, but is that possible with the requirements of the point above > this one? KIOD is only about services started on demand. Do you really need something that starts with the user session? > * For persistent storage (or session persistent like for instance the stash > plugin), what is the best way to get data from the module into the KIO > slave? DBus? Protobuf? shared memory? What I don't get is: if it's only about persistent storage, i.e. on disk, why do you need a kded/kiod module? You could just use the storage from the slave, with a lock file. > [1] At this moment it's for a KIO slave dedicated to tag support backed by > either a JSON or YAML file and does not require file monitoring at all to > work. Then it seems to me you don't need a kded/kiod module. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5