Re: Persistent data with KDED (or KIOD) and a KIO Slave?
On Sat, Oct 14, 2017 at 8:27 AM, David Faure wrote:
> On dimanche 8 octobre 2017 15:22:00 CEST Mark Gaiser wrote:
> > But then i still miss one rather important detail that i can't really
> find
> > anywhere..
> > Lets say I have that module and call it "tags2" (as Baloo already has
> tags,
> > therefore tags2 to prevent naming issues).
> >
> > So i make a dbus service file named:
> > Name=org.kde.tags2
> >
> > And in the "tags2.json" i put:
> >
> > {
> > "KPlugin": {
> > "Description": "Put tags on files and folders.",
> > "Name": "Tags 2",
> > "ServiceTypes": [
> > "KDEDModule"
> > ]
> > },
> >
> > "X-KDE-DBus-ModuleName": "tags2",
> > "X-KDE-DBus-ServiceName": "org.kde.tags2"
> > }
> >
> > What do i do in the client side code to start this module?
>
> You just make a DBus call to the service org.kde.tags, with
> object path /modules/tags2. That will start kiod if needed,
> load the module, and make the call.
>
> The best solution for this is with type safety rather than without,
> i.e. generating C++ from the DBus xml file. See e.g.
> kio/core/kpasswdserverclient.cpp which makes calls to the kiod
> kpasswdserver
> module using the generated OrgKdeKPasswdServerInterface class.
> qt5_add_dbus_interface() is the cmake function for doing that.
>
> > That "client side" can be an IO slave, but it can also be some special
> Tags
> > helper classes to create a new tag name with description and icon or
> such.
>
> Sure, anyone can make dbus calls.
>
> > I need to call something to trigger KIOD to start this module, but i
> can't
> > figure out what.
> >
> > How do i see qCDebug output from kiod plugins anyhow?
>
> In ~/.xsession-errors, or by killing kiod and restarting it in a terminal.
>
>
Hi David,
Thank you for the detailed reply, this really helps and is information that
is quite difficult to find ;)
Re: Persistent data with KDED (or KIOD) and a KIO Slave?
On dimanche 8 octobre 2017 15:22:00 CEST Mark Gaiser wrote:
> But then i still miss one rather important detail that i can't really find
> anywhere..
> Lets say I have that module and call it "tags2" (as Baloo already has tags,
> therefore tags2 to prevent naming issues).
>
> So i make a dbus service file named:
> Name=org.kde.tags2
>
> And in the "tags2.json" i put:
>
> {
> "KPlugin": {
> "Description": "Put tags on files and folders.",
> "Name": "Tags 2",
> "ServiceTypes": [
> "KDEDModule"
> ]
> },
>
> "X-KDE-DBus-ModuleName": "tags2",
> "X-KDE-DBus-ServiceName": "org.kde.tags2"
> }
>
> What do i do in the client side code to start this module?
You just make a DBus call to the service org.kde.tags, with
object path /modules/tags2. That will start kiod if needed,
load the module, and make the call.
The best solution for this is with type safety rather than without,
i.e. generating C++ from the DBus xml file. See e.g.
kio/core/kpasswdserverclient.cpp which makes calls to the kiod kpasswdserver
module using the generated OrgKdeKPasswdServerInterface class.
qt5_add_dbus_interface() is the cmake function for doing that.
> That "client side" can be an IO slave, but it can also be some special Tags
> helper classes to create a new tag name with description and icon or such.
Sure, anyone can make dbus calls.
> I need to call something to trigger KIOD to start this module, but i can't
> figure out what.
>
> How do i see qCDebug output from kiod plugins anyhow?
In ~/.xsession-errors, or by killing kiod and restarting it in a terminal.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
Re: Persistent data with KDED (or KIOD) and a KIO Slave?
On Sun, Oct 8, 2017 at 2:34 PM, David Faure wrote:
> On dimanche 8 octobre 2017 13:02:59 CEST Mark Gaiser wrote:
> > What i want is not just some storage. The storage (the data that
> describes
> > the tags and makes the connection to the files) is something you don't
> want
> > to parse on every request.
> > Also, it could get big if you tag thousands (or millions) of files.
> > You want to parse that data (json file) once and keep it in memory for
> > efficient lookup/creation/query purposes.
> >
> > I don't really want nor need it up and running when the user logs in, but
> > having it start up when something from that storage is requested does
> seem
> > like the way to go.
>
> Yes, so use a kiod module, started on demand.
> This way it even works outside a plasma session.
>
That sounds like the way to go :)
But then i still miss one rather important detail that i can't really find
anywhere..
Lets say I have that module and call it "tags2" (as Baloo already has tags,
therefore tags2 to prevent naming issues).
So i make a dbus service file named:
Name=org.kde.tags2
And in the "tags2.json" i put:
{
"KPlugin": {
"Description": "Put tags on files and folders.",
"Name": "Tags 2",
"ServiceTypes": [
"KDEDModule"
]
},
"X-KDE-DBus-ModuleName": "tags2",
"X-KDE-DBus-ServiceName": "org.kde.tags2"
}
What do i do in the client side code to start this module?
That "client side" can be an IO slave, but it can also be some special Tags
helper classes to create a new tag name with description and icon or such.
I need to call something to trigger KIOD to start this module, but i can't
figure out what.
How do i see qCDebug output from kiod plugins anyhow?
Re: Persistent data with KDED (or KIOD) and a KIO Slave?
On dimanche 8 octobre 2017 13:02:59 CEST Mark Gaiser wrote: > What i want is not just some storage. The storage (the data that describes > the tags and makes the connection to the files) is something you don't want > to parse on every request. > Also, it could get big if you tag thousands (or millions) of files. > You want to parse that data (json file) once and keep it in memory for > efficient lookup/creation/query purposes. > > I don't really want nor need it up and running when the user logs in, but > having it start up when something from that storage is requested does seem > like the way to go. Yes, so use a kiod module, started on demand. This way it even works outside a plasma session. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: Persistent data with KDED (or KIOD) and a KIO Slave?
On Sun, Oct 8, 2017 at 9:46 AM, David Faure wrote: > 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? > I think i do, but there might be another way to get the same result that i just don't know about. What i want is not just some storage. The storage (the data that describes the tags and makes the connection to the files) is something you don't want to parse on every request. Also, it could get big if you tag thousands (or millions) of files. You want to parse that data (json file) once and keep it in memory for efficient lookup/creation/query purposes. I don't really want nor need it up and running when the user logs in, but having it start up when something from that storage is requested does seem like the way to go. > > > * 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 > >
Re: Persistent data with KDED (or KIOD) and a KIO Slave?
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
Persistent data with KDED (or KIOD) and a KIO Slave?
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?... * 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? * 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? [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. I know about Baloo and it's tag support, this is not for that. It's merely a "hey, this would be cool, could it work?" experiment. Cheers, Mark
