From kde-panel-devel Wed Sep 30 14:01:39 2009 From: Fabrizio Montesi Date: Wed, 30 Sep 2009 14:01:39 +0000 To: kde-panel-devel Subject: Re: Remote widgets, the next steps Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=125431935428183 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0379631706==" --===============0379631706== Content-Type: multipart/alternative; boundary=0003255565e64dd2ab0474cbf839 --0003255565e64dd2ab0474cbf839 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 30, 2009 at 3:45 PM, Rob Scheepmaker < r.scheepmaker@student.utwente.nl> wrote: > Cool, I'll append some more information to the remote widgets design doc > when > I've got the time. > Great, thanks. > > > 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. :-) > > Ok, it'll require me to change the implementation to no longer stream > Credentials to a bytearray, but append the different fields as child nodes > in > the message to be somewhat usable, but that's a relatively minor change. > And I > suppose we could always write some libs for php/ruby/whatnot to make > accessing > these plasma soap services easier. > Definitely. Moreover, they already have some very nice APIs for accessing Web Services so if we make a little document with the specs it would already be pretty easy I think. > > > > 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). > > > That would be lovely... such a converter could make a lot of common cases > extremely easy to use. Think of something like: > > Plasma::Service *service = > AccessManager::self()- > >accessService("http://soap.amazon.com/schemas2/AmazonWebServices.wsdl"); > > and then just being able to use service just like any Plasma::Service. > Yes we should aim to something like that. A first step would be at least to have a semi-automatic tool that takes the WSDL as input and outputs a Jolie script that can then be used with loadEmbeddedJolieService and let it handle the dirty work. > > 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 whatever distributed application in a network, hiding the > > complexity from Plasma. > > Orchestrating a distributed application could be something complicated > > (multiparty p2p session) or simply accessing your GoogleMail. ;) > > Cool stuff :p > > Thanks for your feedback. You've given me some useful stuff to make the > implementation more flexible. I'll be improving the implementation, and > will > keep you informed of the progress. > Ok, thanks a lot. :-) Cheers, Fabrizio. --0003255565e64dd2ab0474cbf839 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 30, 2009 at 3:45 PM, Rob Scheepm= aker <r.scheepmaker@student.utwente.nl> wrote:
Cool, I'll append some more information to the remote widgets des= ign doc when
I've got the time.
Great, thanks.
=A0
=

> Also, publishing
>
> > a Plasma::Service using a different technology (like as a SOAP se= rvice)
> > 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 complicat= ed
> 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. :-)
Ok, it'll require me to change the implementation to no longer st= ream
Credentials to a bytearray, but append the different fields as child nodes = in
the message to be somewhat usable, but that's a relatively minor change= . And I
suppose we could always write some libs for php/ruby/whatnot to make access= ing
these plasma soap services easier.
Definitely. Moreove= r, they already have some very nice APIs for accessing Web Services so if w= e make a little document with the specs it would already be pretty easy I t= hink.
=A0
>
> For the future tools, we would just need a WSDL2Jolie converter, since= we
> already have Jolie2Plasma (which converts a Jolie interface to a kconf= igxml
> service descriptor).


That would be lovely... such a converter could make a lot of comm= on cases
extremely easy to use. Think of something like:

Plasma::Service *service =3D
=A0AccessManager::self()-
>accessService("http://soap.amazon.com/schemas2/AmazonWeb= Services.wsdl");

and then just being able to use service just like any Plasma::Service.
<= /blockquote>
Yes we should aim to something like that. A first step wou= ld be at least to have a semi-automatic tool that takes the WSDL as input a= nd outputs a Jolie script that can then be used with loadEmbeddedJolieServi= ce and let it handle the dirty work.


> What I'd like to get working first is to, at least, be able to imp= lement
> local (yes, local) services in Jolie. By doing so I would already gain= a
> =A0lot of power, for example a plasmoid could load this Jolie service = using
> =A0loadEmbeddedJolieService in MetaService and I could use this Jolie = service
> =A0to orchestrate whatever distributed application in a network, hidin= g the
> =A0complexity from Plasma.
> Orchestrating a distributed application could be something complicated=
> (multiparty p2p session) or simply accessing your GoogleMail. ;)

Cool stuff :p

Thanks for your feedback. You've given me some useful stuff to make the=
implementation more flexible. I'll be improving the implementation, and= will
keep you informed of the progress.

Ok,= thanks a lot. :-)

Cheers,
Fabrizio.
--0003255565e64dd2ab0474cbf839-- --===============0379631706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============0379631706==--