"Yahoo! Weather" ion dataengine review

[Shawn Starr]

On Tuesday 12 January 2010 02:06:04 Aaron J. Seigo wrote:
> 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?

I'd like to test that out also. Ideally, any future data sources (ions) I'm 
also working on would be best done in JS to get them done quicker and such.

Thanks, 
Shawn.