[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: JOLIE and Plasma: status and discussion
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2008-11-22 1:39:34
Message-ID: 200811211839.34545.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]