"Yahoo! Weather" ion dataengine review

[Aaron J. Seigo]

On January 11, 2010, Amos Kariuki wrote:
> Marco Martin wrote:
> > On Monday 11 January 2010, Aaron J. Seigo wrote:
> >> On January 10, 2010, Amos Kariuki wrote:
> >> > Is there a need to use both kdereview (svn) and reviewboard or should
> >> > I just submit a patch for review in reviewboard and ignonre
> >> > kdereview?
> >> 
> >> no, if it is in playground, move it to kdereview when it's ready.
> >> 
> >> my biggest question before even looking at the code is licensing. what
> >> are the license requirements that Yahoo! puts on this data?
> > 
> > don't know if it's changed since some time ago.
> > it was free for non profit entities, that would be ok for us...
> > but could have potential problems for distributions
> > (another point for making things scripted and downloadable via get hot
> > new stuff)
> 
> The terms of use for the weather feeds are listed at
> <http://developer.yahoo.com/weather/#terms>, although Marco brings up a
> good point.  In this case assume there's no need to move this to kdereview
> until this is resolved.

i think it's a very grey area, but at least we are ok. it would be a possible 
land mine for our downstreams and i don't know if we should be creating such 
problems for them :)

> I'd actually considered scripting the 'ion' (as Shawn had also suggested in
> the past) but I didn't see any examples of writing a DataEngine (in
> javascript-- which I wanted to use) so I assumed it wasn't possible at the
> time.

it is possible in trunk (probably not in 4.4 given the lack of network support 
then). if you are using svn trunk (even just kdebase/runtime/plasma/ and 
kdelibs/plasma from trunk) we could use this as a real world test case to make 
sure that it does indeed work.

since this can't go into 4.4 anyways, this should work out well. so ... what 
do we need in the JS to make this feasible?

* DataEngine -> check
* network access -> check
* xml parsing -> negatory
* but .... reg exp -> yes!

we do have the rss engine, but i just tested and it won't be of use to us 
here. i think we could get away with reg exp usage, however. which means that 
this should work right now in svn as-is without too much trouble. actual XML 
parsing would be nicer, but i don't think is strictly necessary.

we probably need some additional JS glue in the weather DataEngine Ion 
interface, however, to inject the Ion API. and that looks like it requires two 
methods:

* void reset()
* bool updateIonSource(const QString &source)

the trouble _there_ is that we don't have access to the QScriptEngine since 
that's encapsulated behind the Plasma::ScriptEngine implementation. soo .... 
to get the API into the runtime, we could create a QScript extension plugin 
that has those bits of API and have the DataEngine request it in its .desktop 
file.

then the question would be how to trigger those calls, since they are meant to 
be called from the outside of the Ion (from the WeatherEngine). a possible 
hack would be to create a method in ScriptEngine that allows an arbitrary 
method call to be made (QString methodName, QVariantList args?) that could be 
optionally implemented by the ScriptEngine implementation to trigger calls 
internally.  not sure how i feel about that yet, but it would (in combination 
with the QScriptExtension plugin) allow this to Work(tm)

if you're into that plan, then i can write an example DataEngine in JavaScript 
for you tomorrow and put it into kdeexamples. what do you say?

-- 
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