questions about "remote web services"

[Aaron J. Seigo]

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.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110519/32874ab0/attachment.sig