Re: JOLIE and Plasma: status and discussion
On Tuesday 25 November 2008 00:55:23 Aaron J. Seigo wrote: On Monday 24 November 2008, Fabrizio Montesi wrote: On Monday 24 November 2008 20:24:59 Aaron J. Seigo wrote: On Monday 24 November 2008, Fabrizio Montesi wrote: We would need to support the loading of Jolie scripts anyway (for more complex cases or coding distributed behaviour as backend to a plasmoid), so while this option (the XML one) could be nice I'm wondering if we would end up with too many ways to do the same thing, and I don't like this feeling. ;) yes, Jolie scripts don't look all that difficult to do and we should be able to provide a number of stock scripts that cover the common cases, preventing developers from having to dip into Jolie scripting unless they are interfacing with something that has quirks. so let's just KISS Let's recap a bit about ::access. For quirk-free things, one liner: Service::access(Service::Location location, Service::Protocol protocol = Service::Protocol::Native) Where Service::Protocol::Native is what you need for accessing a Plasma::Service published on another machine. sounds really good. on implementation detail: i'd make it a top level enum in the Plasma namespace (ServiceProtocols?), so you can just do: Plasma::NativeProtocol or Plasma::SoapProtocol from outside of libplasma. Looks fine to me. For adapters: Service::access(QString jolieScript) // perhaps to find a better way than a QString? would this require a location as well, or is that supposed to be in the script? oh wait, i see you answer that next: (another implementation detail: it shoudl be a const QString ; welcome to c++ ;) Would be welcome back to c++. Ah, so many memories. ;) An adapter could require some initialization data (like the URI of the service to bridge to), so some adaptors don't require a location? hm. Correct. In some cases the whole configuration can be just put in the adaptor statically, or the adaptor could be configured for making some kind of dynamic discovery on a service registry automagically. meaning an initial call to its initialize operation just after access-ing it. Easy, but it's not a one liner. what would the initialize call look like? perhaps we can merge the two methods, even.. It depends on the adapter. An adapter may simply need a service location. Another adapter (e.g. a connector to the yahoo search service) could need an applicationKey (a key the service provider gives you to perform identification) or a username/password pair. Also, yeah, let's merge them. Looking at plasma's code, this looks plausible: Service::access(const QString jolieScript, const QMapQString, QVariant initData = null) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JOLIE and Plasma: status and discussion
Ulp! Code! ;) /branches/work/~fmontesi/ I made a first version of the script library for making adaptors. YahooSearch.ol is an implemented custom adaptor that does the following: - takes an init parameter at starting; - composes request data and calls the yahoo web search service converting this data into a querystring; - receives an XML document, parses it, takes the first hit of the web search and returns it to plasma. That adaptor would be used as follows: QMapQString, QVariant initData; initData[applicationId] = my_application_id; Service::access(YahooSearch.ol, initData); Btw1: why QMap and not QHash? Probably a newbie question from a non-qt dev, but I'm interested. It's to avoid the O(n) worst case? Btw2: I was using QMap for simplicity in the discussion (I couldn't find a KConfigGroup p::s example after some svn browsing..), but we should use a KConfigGroup for initData and equip each adaptor with a .operations file, right? In December/January we're going to merge protocol-independent message type support in JOLIE. So in the future we'd be able to automatically generate a .operations file from a JOLIE script. We're stuck to making them by hand until then, though, unless I'm missing something. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JOLIE and Plasma: status and discussion
On Sunday 23 November 2008, Fabrizio Montesi wrote: On Saturday 22 November 2008 02:49:57 Aaron J. Seigo wrote: 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 That's not possible in all cases with our current API, because web services have quirks and quirks require protocol parameters to be passed to Jolie in the common case of a SOAP based service, how common are these quirks? e.g. would we be able to get away with a give me this web service method call that take a JOLIE script as an optional parameter? *thinks* in fact, we could even do this with a bit of magic, making the optional parameter even more.. uh .. optional: * if the applet has a package and the package includes a JOLIE script of the same name * or there is a matching file in the $APPDATADIR/jolie/ file * then use the JOLIE script automatically -- 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
Re: JOLIE and Plasma: status and discussion
On Monday 24 November 2008 18:10:06 Aaron J. Seigo wrote: On Sunday 23 November 2008, Fabrizio Montesi wrote: On Saturday 22 November 2008 02:49:57 Aaron J. Seigo wrote: 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 That's not possible in all cases with our current API, because web services have quirks and quirks require protocol parameters to be passed to Jolie in the common case of a SOAP based service, how common are these quirks? e.g. would we be able to get away with a give me this web service method call that take a JOLIE script as an optional parameter? *thinks* in fact, we could even do this with a bit of magic, making the optional parameter even more.. uh .. optional: * if the applet has a package and the package includes a JOLIE script of the same name * or there is a matching file in the $APPDATADIR/jolie/ file * then use the JOLIE script automatically Yes, and yes. We could also make the protocol configuration loadable by XML files (the XML parsing can be done by MetaService, you can send it as a string), the latter written as something similar to: protocolConfiguration soap use_nice_quirkyes/use_nice_quirk ws_addressing 1 handleCorrelation0/handleCorrelation /ws_addressing /protocolConfiguration We would need to support the loading of Jolie scripts anyway (for more complex cases or coding distributed behaviour as backend to a plasmoid), so while this option (the XML one) could be nice I'm wondering if we would end up with too many ways to do the same thing, and I don't like this feeling. ;) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JOLIE and Plasma: status and discussion
On Monday 24 November 2008, Fabrizio Montesi wrote: On Monday 24 November 2008 20:24:59 Aaron J. Seigo wrote: On Monday 24 November 2008, Fabrizio Montesi wrote: We would need to support the loading of Jolie scripts anyway (for more complex cases or coding distributed behaviour as backend to a plasmoid), so while this option (the XML one) could be nice I'm wondering if we would end up with too many ways to do the same thing, and I don't like this feeling. ;) yes, Jolie scripts don't look all that difficult to do and we should be able to provide a number of stock scripts that cover the common cases, preventing developers from having to dip into Jolie scripting unless they are interfacing with something that has quirks. so let's just KISS Let's recap a bit about ::access. For quirk-free things, one liner: Service::access(Service::Location location, Service::Protocol protocol = Service::Protocol::Native) Where Service::Protocol::Native is what you need for accessing a Plasma::Service published on another machine. sounds really good. on implementation detail: i'd make it a top level enum in the Plasma namespace (ServiceProtocols?), so you can just do: Plasma::NativeProtocol or Plasma::SoapProtocol from outside of libplasma. For adapters: Service::access(QString jolieScript) // perhaps to find a better way than a QString? would this require a location as well, or is that supposed to be in the script? oh wait, i see you answer that next: (another implementation detail: it shoudl be a const QString ; welcome to c++ ;) An adapter could require some initialization data (like the URI of the service to bridge to), so some adaptors don't require a location? hm. meaning an initial call to its initialize operation just after access-ing it. Easy, but it's not a one liner. what would the initialize call look like? perhaps we can merge the two methods, even.. -- 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
Re: JOLIE and Plasma: status and discussion
On Saturday 22 November 2008 02:39:34 Aaron J. Seigo wrote: On Thursday 20 November 2008, Fabrizio Montesi wrote: --- --- Service Exposure --- Example of service exposure: Plasma::Service *s = ...; //Some plasma service obtained in some way. Plasma::ServicePublishingJob *j = s-publish(); Here Plasma::Service::publish() is a wrapper for: addRedirection(d-name, my_unix_server_socket_location, SodepValue(sodep), SodepValue()); where my_unix_server_socket_location should be a Jolie location pointing to your open unix server socket where you're accepting sodep messages, e.g. localsocket:/tmp/mysocket). KServicePublishingJob should allow the programmer to know if the service has been published successfully or not. this looks good; only thing we need to think about now is access control? Affirmative. Is there any technology we can use that comes to your mind or we have to do everything from scratch? PolicyKit perhaps? --- --- Service access --- API: Plasma::ServiceAccessJob* Plasma::Service::access(QString location, SodepValue protocol) Example of service access to a Plasma::Service published in another computer: Plasma::ServiceAccessjob *j = Plasma::Service::access(socket://192.168.1.20:8000/!/Time-2, SodepValue(sodep)); Example of service access to a soap service with a protocol parameter: SodepValue protocol = SodepValue(soap); protocol.children(namespace).append(SodepValue(http://www.webservicex. ne t)); Plasma::ServiceAccessJob *s = Plasma::Service::access(socket://www.webservicex.net:80/geoipservice.asm x , protocol); my first thought is that we need to get rid of socket://192.168... etc. having to know how to create a Plasma::Service URL is probably a bit much. Definitely, agreed. what are the necessary bits? hostname, port and path? we should be able to pass that in as a KUrl and have it assemble the correct path with the needed !'s etc there? A JOLIE location is a URI, and is composed by the following parts (i couple them with the example parts): 1) The communication medium: socket 2) The path specific to the communication medium, whose format depends on (1): 192.168.1.20:8000/someStuff/someOtherStuff.php?querystring=whynototherparam=etc 3) The resource path, which starts after the !: /Time-2 Mmh, I have to think a bit about this and to have a look at QUrl/KUrl. We could also make a Plasma::Service::Location class (possibly extending KUrl..) providing simple constructors and enumerations (we should provide an enumeration for the various communication mediums: Socket, LocalSocket, etc..). also, instead of SodepValue's with strings (no compile time checking), i'd rather expose an enumeration that is mapped internally to the proper protocol string. I agree (and extended that idea to mediums, above). perhaps going so far as hiding SODEP as a detail and just calling it the NativeProtocol (and having that as the defult)? Yes, so that in the future we could even change the NativeProtocol internally if the need arises. Following this line, we should make sure to hide any Sodep keyword from the API. --- --- DataEngine access --- We have two options: 1) make it possible for any DataEngine to wrap a Plasma::Service (is this possible? if so, it looks as the best option to me); could this open other possibilities other than dataengine access? perhaps this reasonment could then be applied also to DataEngine exposure (i.e. DataEngine::toPlasmaService())? it should be possible to publish DataEngines in the same way we can publish Services. in the background it would be using a Plasma::Service, but that would be an implementation detail and one the user wouldn't need to see. this should probably be added to DataEngineManager, and requests from published services can pass through it via the MetaService. so when a Service is published, it woul tell DataEngineManager to listen to the service for publishing requests. 1) API: DataEngine* Plasma::Service::toDataEngine() Example: Plasma::ServiceAccessJob *j = Plasma::Service::access(socket://192.168.1.20:8000/!/MediaPlayer, SodepValue(sodep)); ... DataEngine* myDataEngine = j-service()-toDataEngine(); this particular usage would be wrapped in DataEngineManager to make it ++transparent and so that we don't need to expose things like toDataEngine(); So, if I understand correctly: DataEngine* DataEngineManager::access(same_params_as_Plasma_Service_access); ? I overlooked DataEngineManager, I've just read it now. Yes, it makes sense to put the dataengine access magic there. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JOLIE and Plasma: status and discussion
On Thursday 20 November 2008, Fabrizio Montesi wrote: --- --- Service Exposure --- Example of service exposure: Plasma::Service *s = ...; //Some plasma service obtained in some way. Plasma::ServicePublishingJob *j = s-publish(); Here Plasma::Service::publish() is a wrapper for: addRedirection(d-name, my_unix_server_socket_location, SodepValue(sodep), SodepValue()); where my_unix_server_socket_location should be a Jolie location pointing to your open unix server socket where you're accepting sodep messages, e.g. localsocket:/tmp/mysocket). KServicePublishingJob should allow the programmer to know if the service has been published successfully or not. this looks good; only thing we need to think about now is access control? --- --- Service access --- API: Plasma::ServiceAccessJob* Plasma::Service::access(QString location, SodepValue protocol) Example of service access to a Plasma::Service published in another computer: Plasma::ServiceAccessjob *j = Plasma::Service::access(socket://192.168.1.20:8000/!/Time-2, SodepValue(sodep)); Example of service access to a soap service with a protocol parameter: SodepValue protocol = SodepValue(soap); protocol.children(namespace).append(SodepValue(http://www.webservicex.ne t)); Plasma::ServiceAccessJob *s = Plasma::Service::access(socket://www.webservicex.net:80/geoipservice.asmx , protocol); my first thought is that we need to get rid of socket://192.168... etc. having to know how to create a Plasma::Service URL is probably a bit much. what are the necessary bits? hostname, port and path? we should be able to pass that in as a KUrl and have it assemble the correct path with the needed !'s etc there? also, instead of SodepValue's with strings (no compile time checking), i'd rather expose an enumeration that is mapped internally to the proper protocol string. perhaps going so far as hiding SODEP as a detail and just calling it the NativeProtocol (and having that as the defult)? --- --- DataEngine access --- We have two options: 1) make it possible for any DataEngine to wrap a Plasma::Service (is this possible? if so, it looks as the best option to me); could this open other possibilities other than dataengine access? perhaps this reasonment could then be applied also to DataEngine exposure (i.e. DataEngine::toPlasmaService())? it should be possible to publish DataEngines in the same way we can publish Services. in the background it would be using a Plasma::Service, but that would be an implementation detail and one the user wouldn't need to see. this should probably be added to DataEngineManager, and requests from published services can pass through it via the MetaService. so when a Service is published, it woul tell DataEngineManager to listen to the service for publishing requests. 1) API: DataEngine* Plasma::Service::toDataEngine() Example: Plasma::ServiceAccessJob *j = Plasma::Service::access(socket://192.168.1.20:8000/!/MediaPlayer, SodepValue(sodep)); ... DataEngine* myDataEngine = j-service()-toDataEngine(); this particular usage would be wrapped in DataEngineManager to make it ++transparent and so that we don't need to expose things like toDataEngine(); -- 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
Re: JOLIE and Plasma: status and discussion
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
