Plasma::Service API review

[Aaron J. Seigo]

On Friday 16 May 2008, Kevin Ottens wrote:
> Le Friday 16 May 2008, Aaron J. Seigo a écrit :
> > > itself is "Plasma::Service", that said that probably explains why
> > > KConfigGroup got through. :-)
> >
> > KConfigGroup simply provides an easy way to do a number of interesting
> > things related to key/value pairs.
>
> Well, apart from the defaults (and well, using a QMap instead of a
> KConfigGroup is exactly the same if you already fill the map) what does it
> provides? I really don't get why KConfigGroup is so special in this
> context.

we already have code from ConfigXML to allow a very nice non-code way of 
describing these things that also happens to magically work with our 
configuration system.

i think you're sort of looking at it the wrong way around here: what is so 
great about QMap that is makes up for all the additional API it would require 
to support it properly?

(yes, people don't have to know about KConfigGroup ... but ... do they? if 
they store settings in their applet they do)

> So the "message transmission" metaphor is implied by service interaction
> (despite the implementation). And to me, "message" kind of implies
> "address".

i'll think on it.

> > > That somehow looks like a hook called at initialization time so that I
> > > have the opportunity to call setOperationScheme()?
> >
> > exactly.
>
> Damn, I guessed well. I'm still not sure about the name of this method, but
> I've no better proposal atm.

same here =((

> > > OK, now my proposal for the apidox example if Service and ServiceCall
> > > were splitted:
> > > Plasma::DataEngine *twitter = dataEngine("twitter");
> > > Plasma::Service *service = twitter.serviceForSource("aseigo");
> > > QMap<QString, QVariant> args;
> >
> > and then add methods for getting what parameters are expected for a
> > service, and what types and defaults
>
> Make that a:
> QMap<QString, QVariant> args = service.defaultsForOperation("update");
> Assuming it's prefilled you get the parameters, their defaults and their
> types.

and where do we get runtime documentation? and where can we store these in an 
offline format? i'm actually hoping to use KConfigSkeleton a little more 
agressively here than i currently am.

> > and runtime documentation for them and
> > ... you end up with KConfigSkeleton.
>
> KConfigGroup actually provides runtime documentation?

KConfigSkeleton does.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080516/d49ab366/attachment.pgp