questions about "remote web services"

[Sebastian Kügler]

On Thursday, May 19, 2011 11:26:36 Aaron J. Seigo wrote:
>   On Thursday, May 19, 2011 10:40:11 Sebastian Kügler wrote:
> > On Wednesday, May 18, 2011 16:20:02 Aaron J. Seigo wrote:
> > > * one source per service, e.g. youtube
> >
> > 
> >
> > NOOOOOOOOO! :D
> >
> > 
> >
> > For this kind of stuff, we should completely (== as much as possible)
> > ignore the service itself. So instead of a youtube engine, we create a
> > videoengine (which itself uses youtube as a backend). The backends are
> > interchangeable,
> 
> yes, that's essentially what i'm suggesting. something like:
> 
> Media DataEngine:
>         Youtube
>         Blip
>         Foobar
>         Baz
> 
> and the plasmoid can request a service object for each backend:
> 
> foreach (const QString &service, engine->sources()) {
>     services << engine->serviceForSource(service);
> }
> 
> so one engine with multiple backends.
> 
> an altertnative is to forgoe the DataEngine entirely and just provide a 
> Service plugin which hides the idea that there are multiple providers 
> entirely. the implementation on the Service side would be nearly identical
> to  the above: one front end, multiple back ends.
> 
> however, with a "single Service that hides the backends" approach we lose
> the  ability for provider-specific features (e.g. one service might
> provide the ability to search by "friends", another might not) and the
> ability to easily / conveniently display to the user where it was coming
> from. with a DataEngine approach that information would be contained in
> each source (where one source represents one provider). with a Service,
> that information would need to be encoded in each individual result
> returned, which is probably not great.

Yep, agree. It's not only service-specific features, but also users (/apps) 
who want just one service, like Jérôme who wants to create a youtube player. 
As far as I know, the video engine right now supports queries such as 
"youtube:my little pony" (not sure about the exact syntax).

In the metadata engine, we ended up putting the results under queries (those 
can have one or more types, and the added benefit that the results that come 
from the same queries are shared across visulizations. (The latter being quite 
useful since you then can just create DataSources anywhere in your QML code, 
and end up having more self-contained components. If you need to share the 
DataSource object across QML components, code will be messier and more 
brittle.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9