[Ksecretservice-devel] Clientlib asynchrounous API rationale

Valentin Rusu kde at rusu.info
Sun Feb 13 12:28:09 CET 2011


Hi,

Since several days I started working on the kwlimporter feature.
I integrated it into the daemon and I started debugging the code
initialy drafted by Dario.
Working on the importer would also be the occasion to test the clientlib.
I just pushed the work in progress code.

The clientlib is offerring two classes, KSecretService and
KSecretServiceCollection.
Both of them use lots of asynchronous jobs for doing collection and item
creation.
They return KJob objects the library user must track, then connect to,
then launch.
The development time gets longer and debugging also become cumbersome,
as a single ste-by-step session won't help to get the overall picture of
the routine.
Don't get me wrong, I know asynchronous matters quite well, as I used
them for long operations, involving networks. But here we are working
with rather small objects and very short dbus calls.

Is there any rationale to extensively use KJobs for the clientlib ?

Cheers,
Valentin



More information about the Ksecretservice-devel mailing list