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
