[GSoC]: DataEngine queries in JavaScript

Alessandro Diaferia alediaferia at gmail.com
Sat Jul 10 11:28:09 CEST 2010


Sorry for the delayed reply.

As far as i know making use of services is really useful when asking
additional information to existing sources. And this, as Aaron suggests,
might be done on sources representing each available plugin. So, likely, the
dataengine can have a source for each available backend and services can be
used to perform queries on each backend. I think this is way more elegant
(seriously :). At the same time, though, this wouldn't allow much data
sharing through the dataengine as we're no longer creating a source for each
query but, actually, this isn't mandatory as rarely different applets will
show the same data from the dataengine. The lack for JS bindings for this is
of course mandatory for this to work in our case, and it seems to me a good
point to add them. I think i'll probably investigate on how to add them as
bindings really interest me but i've never had time to have a look at them.

What I suggest to Hayri is still going writing code to fetch data from as
much web services as possible. Later it wouldn't be too hard to adapt such
code to a service implementation.
Please Aaron, correct me if i stated something wrong.

Cheers!

2010/7/10 Aaron J. Seigo <aseigo at kde.org>

> On July 8, 2010, Hayri Bakici wrote:
> > > is this something that belongs more in a DataEngine, or in a Service?
> > > consider
> > > whether the results will be useful to more than one visualization,
> > > whether a
> > > visualization will want to change the query often (versus them being
> > > long- lived), etc..
> >
> > so, what do you suggest then? :)
>
> my suggestion was to consider the above points, formulate answers for them
> and
> decide whether putting large queries into the source name is the desired
> approach.
>
> also think about the resulting code. with queries in the data engine source
> names, strings will be pasted together and then parsed again. with a
> service,
> this wouldn't be necessary: the service would be used to retrieve the
> operationDescription, values set on it and a job started for that
> operation.
>
> probably the biggest downside, and a deal breaker, for doing this as a
> service
> is that there is no scripting support for services right now. that could be
> fixed, probably, and added to the Javascript DataEngine support.
>
> that could lead to an alternate mechanism where the DataEngine lists each
> backend as a source (perhaps putting some information about the bakend as
> the
> data), and the user of the engine could request serviceForSource, returning
> a
> service which can be used to query the service.
>
> it seems like a slightly more natural approach to the problem to me, but i
> may
> not have all the information on the problem space. which is why i asked :)
>
> --
> 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 Development Frameworks
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>


-- 
Alessandro Diaferia
KDE Developer
KDE e.V. member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100710/0c7ea776/attachment.htm 


More information about the Plasma-devel mailing list