something else i just remembered: we're going to want to think about the full round trip "experience":
use case: widget wants to use a web service * it says "give me this web service" -> that should be a one liner with no jargon in it, just the URL of the service and return a Plasma::Service ready to go use case: widget wants to publish it's own service onto the network * it takes a Plasma::Service and, again with a one liner and no jargon it pushes the service by a name passed in; this would get automatically set up using SODEP to the local MetaService and the service's published name namspaced using the ID of the applet. use case: a widget wants to relocate devices * it publishes a service * another device subscribes to that service, asks for the widget to come over * authentication of the request (perhaps user OK?) happens * the service sends across a Plasma::Package and forwards the engines and services the Widget currently holds use case: widget wants to use a service exposed by another Plasma system * it scans the network for an announcer service * it selects a service from it * this results in an auth request on the other Plasma system * on approval, the service is set up on both sides these are the things the API should make easy to do, imho. ok, i have a massive headache atm and am going to lay down ... ugh. -- 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 Qt Software
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
