Data Engines [WAS: KDE/kdebase/workspace/plasma/dataengines/nowplaying]

[Jason Stubbs]

On Monday 14 July 2008 22:36:57 JST, Alex Merry wrote:
> On Monday 14 July 2008 13:51:38 Jason Stubbs wrote:
> > Now, upon hearing of a data engine that reports information about the
> > activity of an alpha piece of software (that uses plasma, mind you)
> > living in kdebase, I instantly wondered why it doesn't live with the
> > alpha piece of software. I'm guessing that "now playing" applets also
> > don't live with the software and, by inference, that either the data
> > engines API doesn't really handle a missing data engine well or that
> > applets don't handle failures from the data engine well. Either of those
> > are a problem.
>
> Well, the now playing data engine abstracts away dealing with a hundred
> different media player interfaces and quirks away, and just gives an applet
> a standard way of accessing the relevant data.  It deals with MPRIS (the
> new standard for accessing media players over D-Bus), Juk and XMMS.  MPD
> support should follow shortly.

The worst I can think of this is that it is the best to do with the available 
tools. In case that wasn't clear, I don't disagree with the data engine given 
the current framework and am merely using it as an example.

> Long-term, I'd like to abstract the "accessing media players" bit out into
> a library (it's already pretty abstracted internally) with optional plugins
> for different players.  Then the nowlistening plugin for Kopete could use
> it, for example.  But maybe MPRIS will make that pointless.

I'm not familiar with MPRIS, but it sounds like it could alleaviate the need 
for a data engine per player _in this case_. It get the feeling it'd be more 
flexible if it could be done at the data engine layer though.

> > Blah, this is getting to long. To ask a question and/or make a point, if
> > there is currently no API to request all dataengines supporting a
> > specific interface, perhaps there should be?
>
> I think the problem is that there's no interface specification in data
> engines.  You just have to know what data to expect.  Some sort of runtime
> introspection is maybe the first step.

(I think) the norm with C++ is to version the data and then readers support 
version X.Y.Z and anything below it. However, the responsibility is moved to 
the writers with dynamic typing. If the spec calls for new data, it is 
provided with a new member. If data should be provided in a new extended 
format, it should also be provided via a new member.

I'm not certain if the data engine framework was designed to follow this 
style. Either way, this should be addressed in some "data engine writer's 
guide". Strict versioning and/or introspection of data engines is a 
possiblity but it'd likely make things a little more difficult.

Applet/data engine contracts aside, I still think it'd be quite useful to be 
able to grab all data engines of a certain "class" if that functionality 
isn't currently available.

-- 
Jason Stubbs