Remote plasma api review.

[Rob Scheepmaker]

Hello all,

With remote services, dataengines and pin pairing working now, another round 
of api review seemed useful. Things are becoming pretty concrete now. See the 
attached file for all new public classes. Not all these classes need to be in 
public api though. Three are convenience classes of which I'm not yet 100% 
sure if they should be included. These are:

* DenyAllAuthorization & PinPairingAuthorization
Both are implementations of AuthorizationInterface. Since not setting an 
AuthorizationInterface in your shell is potentially unsafe (a plugin can then 
do so), DenyAllAuthorization would avoid every shell, even those not 
interested in remote plasma stuff, needing to implement this interface. 
PinPairingAuthorization will fire a simple dialog for pin pairing. With these 
two default implementations most shells (except a future headless plasma 
shell) will have an implementation that suits their need.

* PinPairingDialog
A dialog that asks for a pin for pin pairing. This is used by 
PinPairingAuthorization.  This could be made private, but having it public 
might avoid some duplication in case we want to hide this dialog behind, say, 
a knotification.

The prettiest solution for pin pairing in plasma-desktop would be having a 
knotfication like notification in the systray, with a line edit in the 
notification I think. This would need a protocol in the systray specific for 
this kind of notifications. So this isn't my primary focus, but it would be 
nice if we would add that at some point.

About AccessManager:
accessService was put in AccessManager since accessing a service is async and 
making it a static in Service would make it a bit inconsistent to return a 
KJob that allows access to the service. serviceForSource in dataengine however 
returns a Service directly, so to make that work I needed to add a 
serviceReady signal to Service anyway. ServiceAccessJob isn't really necesarry 
anymore. So I'm thinking of making accessService static in Service. 
Disadvantage is that for applets we'll still need to return a job because we 
can't really instantiate an applet without having obtained it first. So access 
to applets still need a place in AccessManager (and so do functions for 
service discovery) I hate it if there are two methods for service access 
though (Service *serviceForSource and ServiceAccessJob *accessService). 
Another option would be to have accessService in AccessManager and have it 
still return a Service *, but that would make it inconsistent with 
accessApplet.

Please ask me if there are things unclear about the current api, and I'll try 
to elaborate.

Regards,
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remoteplasmaapi.h
Type: text/x-chdr
Size: 16147 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090708/6941a2c6/attachment-0001.h