From kde-panel-devel Thu May 19 13:28:17 2011 From: Sebastian =?utf-8?q?K=C3=BCgler?= Date: Thu, 19 May 2011 13:28:17 +0000 To: kde-panel-devel Subject: Re: questions about "remote web services" Message-Id: <201105191528.17835.sebas () kde ! org> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=130581173602061 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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel