[Kde-hardware-devel] [GSoC] Preliminary UPnP support proposal

[Kevin Ottens]

On Wednesday 7 April 2010 14:15:47 Friedrich W. H. Kossebau wrote:
> Mardi, le 6 avril 2010, à 23:54, Kevin Ottens a écrit:
> > On Wednesday 31 March 2010 09:54:49 Bart Cerneels wrote:
> > > Amarok needs a search interface, hence the upnp-kio slave will need to
> > > implement query support. I doubt this would be developed for a
> > > standalone KIO-slave.
> > 
> > Interestingly I think that such search interface would be a nice
> > extension for KIO, and there's other collection oriented applications
> > which would benefit from it (Digikam comes to my mind).
> 
> To my mind comes Akonadi/Nepomuk as the query wrapper ;)

I think what he has in mind is some "server side" querying. Which isn't what 
Akonadi and Nepomuk are good at. They kind of expect that you got the relevant 
data cached locally (although for Akonadi that might evolve at some point 
since IMAP has support for server side searches and we might want to support 
it).

Now for Amarok itself, maybe it'd make sense to not care about server side 
searches at all. We're talking at possibly not that powerful devices for the 
search, network latency which are generally not great in such multimedia 
contexts... maybe it'd make the experience just smoother to sync locally and 
then do the search client side.

<(not so) crazy idea>
Hmmm, actually an Akonadi powered Amarok could be interesting. Since Amarok is 
trying to sync with more and more different sources (web services, plugged 
devices, DAAP, UPnP and so on), and the tracks metadata is kind of easy to 
serialize, using Akonadi for the syncing logic would make a lot of sense... 
Akonadi itself is only about collections and items after all.
</(not so) crazy idea>

Regards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/amarok/attachments/20100409/52c40513/attachment.sig>