Re: QtJolie and remote widgets
Hi there, I'm in the middle of moving right now (will be more stable after the 1st of September, at my new work place), but I'd be glad to discuss anything related to QtJolie (given that I'm the maintainer of the Jolie interpreter) if questions about Jolie and/or MetaService arise. On Sat, Aug 21, 2010 at 11:59 PM, Dario Freddi drf54...@gmail.com wrote: Hey guys, You probably remember that back in the days (I'm talking about Tokamak in Randa) I helped Rob getting remote widgets in shape for release. This also implied putting a private branch of QtJolie straight into libplasma, due to the fact that the current QtJolie release did not support certain features which were needed for remote widgets. I think Kevin might confirm that this is no longer true - I am not really knowledgeable about Jolie friends so I can't tell. However, I'd really like to remove that code from kdelibs as it definitely does not belong there. However, after a quick look at the code, I found out that such a thing would mean having a hard dependency on QtJolie in kdelibs. So, basically I'd like to know if anybody is planning to maintain remote widgets actively to plan what I should do. I am surely fond to learn Jolie as I'm interested in it, so I can volunteer for at least having a better situation than now. What I'd like to do is abstract the Jolie stack to let kdelibs compile without QtJolie itself (even if this would mean remote widgets won't really work). I also remember some people talking about abstracting dnssd for using $something else, but I'll leave this for the discussion. -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Remote widgets, the next steps
Hi everyone, I've studied the code of the Remote Widgets implementation and I'd like to discuss some internals. Most of the following (if not all) could be already known, anyway. If I understood the implementation correctly, the parameters for operation calls to a remote Plasma::Service are serialized as a byte array, which is then deserialized on the other side. This works just fine between a Plasma instance and another Plasma instance, but won't work with other technologies (because the message isn't properly structured, so for example a SOAP service would just see a stream of bytes inside the SOAP body instead of an XML tree of parameters). Moreover, if I wanted to use a Jolie script to implement a complex Plasma::Service that, i.e., implements a peer to peer multiparty game/chat/something I couldn't do it for the same reasons. What needs to be done is to create the message by reflecting the parameters structure, so one child node for each parameter. Another problem I've seen is that the remote widgets framework makes use of special operations like startOperationCall, and others for checking access control. There is nothing wrong with this, but then for performing normal operation calls you are passing the operation name in the message data, not in the message headers. This breaks interoperability with everything because you've got two levels of operations, the special one and the normal one, whereas services have just one. A quick solution for this would be to make these operation names standard and reserved for Plasma::Service, or (better) to hide them behind a specific resource name (e.g. PlasmaControl). Last, the current implementation is just using tcp sockets and sodep, but I think that's obviously known. :-) Cheers, Fabrizio. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Remote widgets, the next steps
On Tue, Sep 29, 2009 at 4:30 PM, Rob Scheepmaker r.scheepma...@student.utwente.nl wrote: I never really considered the case of implementing a native Plasma::Services in jolie script since that could get a bit complicated anyway, considering the access control/message signing, plus additional overhead like the fact that we should send over valid kconfigxml describing the parameters. Message signing and access control shouldn't be too hard to code: I'd like to write some sort of standard Jolie library for handling Plasma services and to distribute it with Jolie. Could you provide the workflow specs? (describing them here is fine) We had some work on generating kconfigxml automatically from Jolie interface files, see http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/tools/jolie2plasma/ Only problems are w.r.t. certain data types (which I see you already know by your explanation in the following). Also, publishing a Plasma::Service using a different technology (like as a SOAP service) would be tricky since the access/control and message singing would make this SOAP service quite complicated to use Well, a lot of SOAP services in the industry there have very complicated specifications on how to access them. I don't think anybody would kick us for some security parameters that need to be added to messages. :-) I mostly considered the case of accessing something like a SOAP service from plasma as something seperate, where we could leverage jolie, but need to use a different approach. In that case we would want some wsdl to jolie converter for example, since it would be a pain if a developer that just wants to use a web service needs to do that by hand. And a wsdl to configxml convertor, since Plasma::Service need to provide valid configxml. And a seperate Service implementation that doesn't do any access control stuff and just calls operations on the service, but this would be a relatively small and trivial class to make. I could at some point add a function to access manager to access any non native plasma service through a Plasma::Service. If/when (?) there are converters to help us with the wsdl, it should be very easy ... both to implement, and to use. This is true, but if we provide a way to use the loadEmbeddedJolieService in MetaService so to load custom Jolie scripts and see them as a Plasma::Service I can at least access SOAP services by making a Jolie script. In a lot of cases making a Jolie script for accessing a SOAP service is easy, and there are hard cases in which I would like to use a Jolie script even if I had all the automatic converters because there could be a necessity for some additional orchestration (security protocols, handshaking etc...) which Plasma doesn't support. For the future tools, we would just need a WSDL2Jolie converter, since we already have Jolie2Plasma (which converts a Jolie interface to a kconfigxml service descriptor). The problem of streaming the parameters is not entirely solvable. The parameters passed to any Plasma::Service are a QVariantMap. I could obviously put every element of the map as seperate child node, but they're still QVariants, and those will need to be serialized/deserialized. I could use the 3 native sodep types: string integer and double directly, but this doesn't solve the issue for all the types out there, just for some of the most common ones. I suggest we go this way: - if a parameter can be cast to a sodep data type, convert it; - otherwise, serialize it. Nevertheless, maintain the separate child node structure. This way we already have a mostly working implementation (I imagine most parameters in Plasma are integers, strings, doubles and booleans?) and I can start adding sodep data types appropriately as we see necessary. Another problem I've seen is that the remote widgets framework makes use of special operations like startOperationCall, and others for checking access control. There is nothing wrong with this, but then for performing normal operation calls you are passing the operation name in the message data, not in the message headers. This breaks interoperability with everything because you've got two levels of operations, the special one and the normal one, whereas services have just one. A quick solution for this would be to make these operation names standard and reserved for Plasma::Service, or (better) to hide them behind a specific resource name (e.g. PlasmaControl). Yeah, I suppose I could put the actual operations in the operation name instead of the startOperationCall parameters. That would already be a great step forward, yes. What I'd like to get working first is to, at least, be able to implement local (yes, local) services in Jolie. By doing so I would already gain a lot of power, for example a plasmoid could load this Jolie service using loadEmbeddedJolieService in MetaService and I could use this Jolie service to orchestrate
Re: Network transparancy api review.
On Tue, Jun 23, 2009 at 7:05 PM, Rob Scheepmaker r.scheepma...@student.utwente.nl wrote: Hello everybody, [cut] Hi Rob, just a quick comment about identifying remote machines. What about combining public key authentication with the bluetooth pairing method (the host writes a PIN, the client is asked for the PIN, the two PINs must match)? This way if the user is too lazy to check the public key we reduce greatly the attacker's possibilities. Using this approach we'd have to face the fact that a lazy user could write 1234 as a PIN, too: the host side UI for writing the PIN should warn the user that things like 1234 are not such a good idea. Bye, Fabrizio. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC proposal draft: network transparency.
On Wed, Mar 25, 2009 at 9:24 AM, Kevin Ottens er...@kde.org wrote: On Monday 23 March 2009 18:15:36 Rob Scheepmaker wrote: I've mentioned my interest in this GSoC project before. Now I've made a first draft of a proposal for GSoC. Excellent! Indeed :-) A way to synchronize changes between multiple shared applets. It should require only very little effort for applets to publish changes to all shared applets, or receive changes from other shared applets. Again, I will use Kevin Otten's library to make this easy. Keep in mind that right now I'm concentrating on the using services part of the library. I'm somehow forced to put the exposing services part on hold because I'm waiting on some changes on Jolie's Metaservice side. AFAIK Fabrizio is working on that, but I don't really know when that'll deliver. At italianaSoftware we just finished the design of a feature I was waiting for which should solve all our problems w.r.t. security and service exposure. So the ETA is not too far away. ;) The security implications will need to be thought trough. We will need some some way of authenticating systems that are allowed access to published applets or activities. Oh, and once the library is ready to expose services, it's likely that for the first iteration it'll be a huge security hole. Jolie won't yet provide the security model, which means you'll be left on your own to authenticate clients. OTOH once Jolie provides a security model it won't be necessary for you to deal with that anymore (or at least it'll be much less complicated). The new feature I'm gonna put in Jolie should make it easy to inject security into unsecure services. We would still need to think the security model we want in our particular case (Plasma+Jolie). There are various possibilities, and the user should be prompted by Plasma when necessary. The sooner we start thinking about this, the better. Timeline April 20 – May 22: Community bonding period, experiment with Kevin's library, draft and discuss the required api. Draft and discuss the interfaces for the required services. Hmmm, April 20, I'll seriously have to move faster, and kick Fabrizio harder. ;-) My god, we will have to write some documentation! ;-) I'm seriously looking forward to your work. Obviously when the time comes I'm willing to mentor or co-mentor you. So far it's been always a pleasure to work with you, I'd be a fool not to participate in your mentoring. :-) I'm interesting in helping co-mentoring this, too. This will really put the qt/jolie integration to work. Bye, Fabrizio. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: SoConcepts
Forgot to mention: We've got plans (and all the necessary dependencies and some helper code in svn already) to make a WSDL importer for Jolie (which can also be used dynamically, hence obtaining a Generic WSDL-declared service). We already have a working prototype of the opposite (automatic generation of a WSDL file from a Jolie program), but it needs to be code-restyled a little before entering Jolie's trunk. So a good option would be to work directly on the Jolie-WSDL integration, if there's someone willing to code in Java. If such an opportunity arises I offer myself as mentor because I'll need to mentor someone either way, under one scope (GSOC) or another (University/Work/whatever). 2009/2/20 Aaron J. Seigo ase...@kde.org On Friday 20 February 2009, Fabrizio Montesi wrote: Yo everyone. In the GSoC ideas page there's this entry related to Plasma: Project: Generic SOAP Dataengine. That projects overlaps with the work currently being done with the integration of Jolie. Does anyone know anything about that entry (it's been put anonymously)? hm, that should probably be Generic SOAP Service. a dataengine doesn't really make sense for that use case. Definitely. ;) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma .operations file to JOLIE interface converter and plasma::(dataengine/service) return value typing
Asraniel awesomely produced a working converter already! :-) Code's attached. I've already commented it a bit and it's already been patched for more JOLIE compatibility. Three points remain: 1) there are some plasma types jolie doesn't support, such as bool and uint udouble. They are currently converted to integers or doubles. I still need to think about this. 2) plasma team comments about style or whatever by some C++ coder 3) when (2) is finished, where to upload this thing in svn? src.tar.gz Description: GNU Zip compressed data ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Jolie and Plasma.... and Akonadi?
Looks like we are going to the same direction I took for giving Java support to enterprise applications italianaSoftware and eos-software are developing: metaservice-java. http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/support/metaservice-java/ See the MetaService class: http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/support/metaservice-java/src/joliex/metaservice/MetaService.java?view=markup We could make something similar. If we want to go further, we could make an abstraction for contacting a Jolie service (JolieService) supporting generic calls to operations (callOneWayOperation, callRequestResponseOperation etc...) and then build a MetaService class on top of it. This could be the best solution. How does that look? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Jolie and Plasma.... and Akonadi?
My main problem for UPnP support is time, but as I've said I'd be willing to mentor the JOLIE side of that. =) Perhaps once we get this library and some end-user benefits (like Plasma::Service integration and a plasmoid that makes use of it), we will gain enough interest and get someone to cooperate with us.. or I'll find a thesist willing to do this. ;) 2009/1/28 Kevin Ottens er...@kde.org On Wednesday 28 January 2009 09:33:25 Aaron J. Seigo wrote: On Wednesday 28 January 2009, Kevin Ottens wrote: I somehow assumed this library would end up as some private classes in libplasma but perhaps it makes sense to even go for pure Qt API and for kdesupport to give it the chance for wider adoption? (actually that'd make i think it makes sense if plasma isn't going to be the sole point of contact for Jolie. i figured it'd take a bit longer for that to happen, but i should learn to stop underestimating the kde community's amazing pace of movement ;) OK, I'll make it a goal for Tokamak II then. Now that I think of it, if I ever manage to push Fabrizio to have UPnP support in Jolie I might even use that in Solid at some point. I think I'd prefer having one solution for all our service needs, than talking to Jolie in some cases or some other daemon in some others. Regards. -- Kévin 'ervin' Ottens, http://ervin.ipsquad.net Ni le maître sans disciple, Ni le disciple sans maître, Ne font reculer l'ignorance. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Jolie and Plasma.... and Akonadi?
Yes, I'd like that very much, as I'd like to sponsor it as the official C++ library for interacting with JOLIE during research meetings, the industry, the JOLIE website and so on... ;) We should discuss the API for that then. I'm willing to make some changes to the API of metaservice-java if we do that in 2 or 3 months (JOLIE 1.0 will enter RC after that, and metaservice-java will have its API frozen for some time), provided that we don't completely overhaul it but i don't think that'll be the case. 2009/1/28 Aaron J. Seigo ase...@kde.org On Wednesday 28 January 2009, Fabrizio Montesi wrote: How does that look? quite sensible; if we keep it similar to the java classes as well then we can increase the amount of transferable knowledge betwee the systems :) -- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Jolie and Plasma.... and Akonadi?
IMO the two projects could share a private library for interacting with MetaService and use its operations. Something like: MetaService* s = MetaService::connect( /tmp/metaservice_socket ); Job* j1 = s-addRedirection(...); Job* j2 = s-loadEmbeddedJolieService(...); [...] For instance, by using addRedirection one could expose a local C++ service with any of JOLIE's supported protocol (that's a plasma use-case). By using loadEmbeddedJolieService one can make use of JOLIE adapters (as I described in my last mail in the jolie+plasma api discussion thread). Again, by using addRedirection one could also put in place service access to an external service (web service, rest service or whatever), etc.. 2009/1/27 Aaron J. Seigo ase...@kde.org On Monday 26 January 2009, Fabrizio Montesi wrote: today igorto and vkrause (akonadi people) jumped in #jolie to speak about the possibility to integrate akonadi with Jolie. They're still investigating, but the thing surely seem possible and sound. I think that the best thing to do would be to share as much information and work as possible.. no reason to have duplicate work, libraries or whatever comes up. So my point is: where do we discuss? i'm on both the kde-pim as well as the plasma list. don't know though, what kind of cross over would there end up being between akonadi and plasma's usage of jolie i wonder? -- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jolie and Plasma.... and Akonadi?
Hi everyone, today igorto and vkrause (akonadi people) jumped in #jolie to speak about the possibility to integrate akonadi with Jolie. They're still investigating, but the thing surely seem possible and sound. I think that the best thing to do would be to share as much information and work as possible.. no reason to have duplicate work, libraries or whatever comes up. So my point is: where do we discuss? Options are: 1 - people interested in integrating jolie join plasma-devel (as we already have discussed plenty of things here) 2 - we use jolie-de...@lists.sourceforge.net (as it's still a newborn list so no traffic headache) 3 - we make another ML for this (this looks overkill to me, but i cite the option nevertheless) What do you think? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma studio
On Wednesday 21 January 2009 17:25:29 Aaron J. Seigo wrote: On Wednesday 21 January 2009, Riccardo Iaconelli wrote: informed, i started working a bit on the plasma studio. for now there's nothing at all to show, i'll see if i can get something at least... with some buttons, an editor or an interface (:P) for the tokamak. can we meet up somewhere online before tokamak and go over this? i've got a ton of notes on this now, and it would be good to coordinate. it's one of the things i plan on spending some of my time on as well for 4.3. it's certainly a big enough project for at _least_ 2 people though =) When you reach that point, I'd like to brainstorm about how to make plasma studio helping the programmer to design good DataEngine and Service interfaces. Is that an objective? It would be nice to have a simple gui for creating .operations file entries, for example. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma studio
2009/1/21 Aaron J. Seigo ase...@kde.org On Wednesday 21 January 2009, Fabrizio Montesi wrote: On Wednesday 21 January 2009 17:25:29 Aaron J. Seigo wrote: On Wednesday 21 January 2009, Riccardo Iaconelli wrote: informed, i started working a bit on the plasma studio. for now there's nothing at all to show, i'll see if i can get something at least... with some buttons, an editor or an interface (:P) for the tokamak. can we meet up somewhere online before tokamak and go over this? i've got a ton of notes on this now, and it would be good to coordinate. it's one of the things i plan on spending some of my time on as well for 4.3. it's certainly a big enough project for at _least_ 2 people though =) When you reach that point, I'd like to brainstorm about how to make plasma studio helping the programmer to design good DataEngine and Service interfaces. Is that an objective? Yes. It would be nice to have a simple gui for creating .operations file entries, for example. Yes. we need to find ways to disagree more. arguments, i'm told, are a part of any healthy relationship. ;-P Yes. ... DOH! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma .operations file to JOLIE interface converter and plasma::(dataengine/service) return value typing
Hi everyone,
today I was chatting with asraniel on #plasma about making an automatic
generator of JOLIE interfaces from Plasma::Service .operations XML files and he
decided to go ahead and start the project.
Such a tool would allow for fast, type-safe JOLIE adapter prototyping
(manually porting such interfaces and parameter types would be ... boring, to
say the least). It is to be made in C++, to take advantage of KDE and plasma's
API for accessing the .operations file.
Current objective is to make a command line tool working like:
plasmaoperations2jolieinterface source.operations dest.iol
Suggestions for a name for this tool or other aspects in general?
You can find an example of a correct conversion in attachment, to make it clear
what we want to achieve.
Moreover, though operation call parameters are typed in .operations files, it
seems there is no mechanism for typing a DataEngine or Service return value.
This is supported by JOLIE (as one can leave the return value of an operation
call untyped), but I was wondering: is there any future plan regarding this?
Bye,
Fabrizio.
PS: another thing for the future will be to make the opposite tool (JOLIE
interface to Plasma .operations file, so to import automagically already
defined
JOLIE service interfaces), but that's another story. =)
--- Plasma .operations file for nowPlaying
?xml version=1.0 encoding=UTF-8?
!DOCTYPE kcfg SYSTEM
http://www.kde.org/standards/kcfg/1.0/kcfg.xsd;
kcfg
group name=play/
group name=pause/
group name=stop/
group name=previous/
group name=next/
group name=volume
entry name=level type=Double
labelThe required volume level, as a real number between 0 and
1./label
/entry
/group
group name=seek
entry name=seconds type=Int
labelThe position to seek to, in seconds. Must be between 0 and the
track length./label
/entry
/group
/kcfg
--- JOLIE equivalent format
type VolumeRequestType:void {
.level:double
}
type SeekRequestType:void {
.seconds:int
}
interface NowPlayingInterface {
RequestResponse:
play(void)(undefined),
pause(void)(undefined),
stop(void)(undefined),
previous(void)(undefined),
next(void)(undefined),
volume(VolumeRequestType)(undefined),
seek(SeekRequestType)(undefined)
}___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kde community plasma integration
On Tuesday 13 January 2009 23:07:37 Cornelius Schumacher wrote: On Tuesday 13 January 2009 19:28:08 Fabrizio Montesi wrote: On Wednesday 07 January 2009 16:17:03 Frank Karlitschek wrote: [lots of cool things...] Yes, definitely. I'm lacking the time to write a detailed response to it right now, but I'm really looking forward to get community web services integrated with the desktop. iirc Cornelius raised the interesting problem of respecting KDE's preferences for connections... we should spend a minute about how much of that we want in Plasma-JOLIE integration and how to do it: a dbus service by KDE's side that JOLIE would access? JOLIE reading some KDE config file? It's not only about simply reading config options. It's also about sharing credentials via kwallet, having a central store and management UI for cookies, certificates, cache, and consistent handling of offline mode, progress information and some other stuff. I think the best solution would be, if JOLIE could use kio-slaves as transport layer. This would naturally give great integration with other KDE applications without having to implement all the configuration and shared infrastructure again. I agree, but using KIO will not be so straightforward. I need to check if KIO allows for all the HTTP header manipulation Web Services need through its D- Bus interface (if something is needed and not supported, I shall mention it and ask for a patch in KIO, kde-devel would be the right place for that right?). I care for saying that changing the protocol JOLIE uses in the future won't cause any problem, i.e. we can start using the JOLIE http protocol and then change to KIO as soon as the integration is ready with some trivial changes in the JOLIE plasma adaptors (probably something like changing http to kio_http in the communication port protocol configurations). I didn't find any documentation about KIO's dbus interface, maybe the best thing to do is to look at the source code? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kde community plasma integration
On Wednesday 07 January 2009 16:17:03 Frank Karlitschek wrote: [lots of cool things...] I've finished all the necessary things to interact with Open Collaboration Services. Only thing missing is SSL support, but I've got someone working on that. @Aaron and whoever follows the JOLIE mail thread: making JOLIE adapters to these specs is easy, and OCS' specs for the provider file are 100% compatible with JOLIE thanks to a discussion I and Frank had at Akademy, so we could also implement some kind of a selector for OCS provides. =) iirc Cornelius raised the interesting problem of respecting KDE's preferences for connections... we should spend a minute about how much of that we want in Plasma-JOLIE integration and how to do it: a dbus service by KDE's side that JOLIE would access? JOLIE reading some KDE config file? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kde community plasma integration
On Tuesday 13 January 2009 19:55:37 Aaron J. Seigo wrote: On Tuesday 13 January 2009, Fabrizio Montesi wrote: iirc Cornelius raised the interesting problem of respecting KDE's preferences for connections... we should spend a minute about how much of that we want in Plasma-JOLIE integration and how to do it: a dbus service by KDE's side that JOLIE would access? JOLIE reading some KDE config file? reading a config file would be brittle: changes on the kde side would need to be reflected on the jolie side, and then we'd get into version number games between the two. either a common library should be used or simply passing the parameters to jolie from the kde side would be the most sesnsible. and passing them to jolie is probably the easiest. We could simply put some kind of operation on MetaService to update its connection settings, which KDE could call anytime it wants. The problem just becomes what kind of support JOLIE must offer. JOLIE does not currently support HTTP proxies, though that shouldn't be hard to implement. Connection timeouts should be easy, too. Anything else? These things make for good junior jobs for wanna-be JOLIE contributors, I'll make a list on the JOLIE website. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
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 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 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
JOLIE and Plasma: status and discussion
Hi everyone, this is a recap mail about the current status of the integration of JOLIE and Plasma, so that everyone can jump in and to make discussing it easier. As you can see in SVN, the JOLIE integration layer didn't make it for KDE 4.2. That's to avoid cluttering with Plasma's API when the project is committing to binary compatibility. What we'll do instead is: - create a libplasmajolie project (in extragear?); - put the integration layer there, extending Plasma::Service with something like Plasma::PublishableService; - release it along with KDE 4.2.x, so that people can start studying and using it asap; - merge Plasma::PublishableService with Plasma::Service in KDE 4.3 trunk. That allows us to test the API and the quirks of the integration with complete freedom w.r.t. Plasma's compatibility until KDE 4.3, giving also the possibility to write plasmoids exploiting that API as soon as possible. Basically, what we already have is the following: - the Jolie modifications to satisfy Plasma's needs (this is in Jolie's SVN); - MetaService: the Jolie service allowing for service exposure and access (see http://techbase.kde.org/Projects/Plasma/Services); - QtSodep: a Qt library implementing SODEP, a fastclean binary protocol for communicating with Jolie (/branches/work/~ervin/sodep); - a reference implementation for the wrapping of MetaService in a library: metaservice-java (this is in Jolie's SVN playground); - perhaps something more on aseigo's side, but still incomplete? What we need to do is: - wrap addRedirection and loadEmbeddedJolieService in a couple of Plasma::Service C++ methods (simply translating the code from metaservice-java will suffice, it's just using the C++ classes of QtSodep instead of what I use there); - use those methods to implement service exposure and service access; - for service exposure, we also need to open a local (unix) server socket in order to make a Plasma::Service able to receive messages from the network via MetaService; - make a nice API; - make it possible for the programmer to automatically expose and access DataEngines. For some documentation about MetaService's interface: http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/support/metaservice- java/src/joliex/metaservice/MetaService.java?view=markup http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/playground/metaservice/metaservice.iol?view=markup The main problems right now are to review a good API and the automatic exposure/access of DataEngines. So everything below here is under heavy discussion, comments are really appreciated. Also, please ask anything you need about these arguments, I've just jumped in plasma-devel so I'll read mails sent here. =) I don't code C++ since some time, so I'm probably missing some details (like QString instead of QString or something...), please bear with that. Also, I'm not a KDE coder, so I could say some terrible things on using KJobs etc. Whenever we ask MetaService for publishing or accessing something, we're calling its addRedirection operation. So, internally, we'll probably have something like in metaservice-java, i.e.: KMetaServiceJob* addRedirection(QString resourcePrefix, QString location, SodepValue protocol, SodepValue metadata) we return a job so that the GUI doesn't get stuck waiting for responses from MetaService. When MetaService successfully adds a redirection, it publishes it under its own location. Suppose that MetaService's location is socket://localhost:8000/ and you're publishing something with resourcePrefix Time, then you'll have that your redirection will be available at this url: socket://localhost:8000/!/Time. If there is already a /Time redirection, MetaService will append a number, e.g. /Time-2. MetaService notifies this choice in its response, so KMetaServiceJob should make this information available. KMetaService job should be private. --- --- 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. --- --- 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);
