JOLIE and Plasma: status and discussion

[Fabrizio Montesi]

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 QMap<QString, QVariant>& 
initData = null)