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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
