Remote plasma api review.

[Rob Scheepmaker]

On Wednesday 08 July 2009 22:27:24 Aaron J. Seigo wrote:
> personally, what i'd expect is the ability to set the authorization
> interface either using an AuthorizationInterface* or by just calling
> AuthorizationManager::setAuthorizationInterface() with a enum as the
> parameter, with the enums mapping to these internal classes.
>
> so a shell can either go "standard" or "custom".
>
> the standards might include DenyAllAuthorization, PinPairingAuthorization,
> CertificateAuthorization? pin pairing should include certificate auth, i'd
> think, as well... but yes, then there's no need to make any of it public.

Sounds like a good idea. Indeed PinPairingAuthorization will only actually do 
pin pairing if there isn't already some trusted gpg key or something like that 
we could use to validate it's identity. 
I assume btw that it's safe to, when adding support for GPG, sign the 
QCA::PublicKey we use for signing/validating, and check if that GPG key is in 
some trusted key ring? That way, there's just a single code path for signing 
validating (just RSA or DSA keys, which doesn't really mind since they both 
implement QCA::PublicKey), and GPG (which has a completely different API in 
QCA) is just some addition on top of that. And the shell can just check 
Identity::isTrusted() to see if it is trusted even if in the future different 
method for establishing trust are used.
Hmm, now that I'm thinking about the Identity class: what if I, besides 
validating signatures, also put signing there (with identities that aren't the 
local machine just not being able to sign because of the lack of a 
privatekey), create some identity "me" in AuthorizationManager, and a second 
constructor that creates a private/public key pair. Then, if instead of 
QCA::PublicKey the constructor accepts the key as a QByteArray, ALL QCA 
related stuff (hmm, except tokens, well, let's say ALL crypto) will be 
encapsulated by Identity. Hell, we could then even switch out QCA entirely for 
something else in the probably unlikely case that QCA would become 
unmaintained. I'd like that....

> something else in AccessManager:
>
> ServiceAccessJob* accessService(KUrl location) const;
>
> the url is said to be, in the dox:
>
> * @param location a valid JOLIE url
>
> besides not wanting to really expose JOLIE too much in the api, this is not
> going to work out well for other modes of transit. same will go for
> retrieving applets.
>
> while it's just fine to have only JOLIE created right now, i think we
> should keep the possibility open for other mechanisms. JOLIE may not be an
> option on some devices, particularly very small ones. so while plasma://
> would be synonymous with "this is a JOLIE driven service" or "this is an
> applet we're going to grab using JOLIE", i do plan on writing an emb:// (or
> whatever) handler that does things in a rather more direct fashion between
> plasma and a device. the only major difference is the kind of service it
> returns (it would obviously speak a slightly different protocol) and how it
> retrieves the applet/service/etc.
>
> now, this doesn't impact the external API at all, but the apidox should
> probably be changed and the backend code should remain flexible enough to
> have this added in future.

Hmm, I didn't really think about bypassing jolie, but it's a good idea, and 
not hard to accomplish. Only in AuthorizationManager there are currently some 
Jolie::Message parameters for certain functions, but these functions usually 
only need a couple of fields from such a message, so I could replace them with 
some QByteArrays/QStrings. In which case the only place that does Jolie 
specific stuff would be RemoteService/RemoteServiceJob/ServiceProvider. Which 
would be neat: for a different future protocol (what IS emb:///?) All you need 
is a different implementation of those classes, and you'll have your different 
protocol. At the exact same way we could even version the JOLIE based 
protocol: See if the other side supports the newer version and then 
instantiate RemoteServiceV2 instead. We could even make those plugins, but 
let's not start with that :p

> > I hate it if there are two
> > methods for service access though (Service *serviceForSource and
> > ServiceAccessJob *accessService).
>
> there are actually more than two; you can ask for a service from a local
> plugin as well using Plasma::Service::load. there's nothing that says
> services must be attached a DataEngine, after all.
>
> that said, they all have completely different use cases, and in the case of
> serviceForSource, if it's a remote engine it should be using accessService
> in the background. so for the users of services today in plasma, it will be
> completely transparent and the API is just there as an implementation
> detail to them, no?

Yeah, true.

> > Another option would be to have
> > accessService in AccessManager and have it still return a Service *, but
> > that would make it inconsistent with accessApplet.
>
> i think the accessService should just return a Service*, since Service is
> (now, anyways :) fully async, and accessApplet should return a job because
> applets are _not_ async. it's not inconsistent really, it's just that the
> two kinds of objects behave very differently.

Ok, so to summarize:

Default implementations AuthorizationInterface become private and settable by 
Enum
Only have Jolie specific stuff in 
RemoteService/RemoteServiceJob/ServiceProvider
Have all QCA crypto stuff in identity.

Alright?
Let's put on my refactoring hat.
... pitty refactoring support for kdevelop is still a WiP :p


Oh, on a related topic:
Suppose we're going to connect to a remote nowplaying applet. That applet uses 
the nowplaying dataengine and possibly nowplaying service. So when we 
succesfully connect with the service that provides the applet, that service 
should also:
* make sure nowplaying dataengine is published (service will be published as a 
response to serviceForSource)
* create an AuthorizationRule for that identity that allows it access to 
nowplaying dataengine and applet.
So we need tok now which other services an applet uses so we can put all the 
light on green. (people probably wouldn't like having to Pin pair for all 
engines used by an applet as well :p). How it currently works however is that 
the applet's config contains a section with names of dataengines and the urls 
they point to. Which is not enough to acccomplish this.
So there are two ways to do this:
* Include a list of 'dependencies' in the applet's .desktop
* Invoke a dataEngine operation on the service providing the applet that will 
publish the dataengine (if not already published) and add a rule allowing the 
caller to access that engine.
the last option looks quite good, but it does give a little less flexibility. 
Theoratically, you could now configure a local applet to use dataengine a from 
machine A and dataengine b from machine B, which will be lost with that 
approach. I don't know how important it is to be able to do that kind of 
insane stuff ;)

Regards,
Rob