Summer of Code: Draft of Playdar Proposal

[Leo Franchi]

On Fri, Mar 26, 2010 at 5:48 AM, Bart Cerneels <bart.cerneels at kde.org> wrote:

>>
>>   That is, on top of a common underlying structure, it makes sense to
>> me to have two separate views of the potentially vast catalog of music
>> that Playdar may be able to access.  There's the collection view,
>> which provides the standard method of browsing for a user selected
>> subset of the catalog, and a service view that allows the user to find
>> any specific thing in the entire catalog.  I think it might be
>> possible to do this entirely as a Collection, a fancy config UI, and a
>> context applet, but I also think this is likely to come off as less
>> well integrated than a setup with a Collection to hold on to and a
>> Service to help find things to [not] add to the Collection, (this also
>> happens to be how I might intuitively want to describe it regardless
>> of implementation).
>>
>>  - Andy Coder
>
> That seems to be the best compromise, though in this case it's also
> the most sane implementation.
>
> Seems like "source" in the JSON result can be used in a query of the
> form /api/?method=resolve&source=wendys-laptop to get the content for
> the Collection part.
>
> So I suggest this kind of workflow:
> 1) Use the playdar internet service to query for tracks.
> 2) Get a list of results that also mention the resolver for each track.
> 3) Click on the resolver icon/name and select "Use this resolver as a
> collection...", read the detailed explanation in the popup dialog and
> click OK.
>
> 4) From now on that resolver will have it's own entry in "Local Music"
> with a full list of it's tracks.
>
> Each resolver should have it's own Collection instance. That way when
> a resolver is not available, at work instead of at home for instance,
> the home-nas resolver and all it's tracks won't even show up in the
> collection but the work-desktop resolver does. It's a lot less
> confusing to have a complete collection not be available instead of a
> bunch of tracks "disappearing" from the playdar collection.

I disagree. Users shouldn't even have to know what resolvers are.
That's one of the big benefits that playdar brings---it disconnects
the user from having to keep track of what music comes from where. The
point is the user can search for a song, find it, and play
it---without having to think about where it's coming from. The whole
point of playdar is to hide the resolvers from the user. As soon as
the user has to interact directly with the resolvers, we break the
separation and lose part of the flexibility that makes playdar so
great. Users *definitely* should not need to "configure" each resolver
to do what they want---imagine if there are 10, 15 resolvers. It would
become mad. The playdar implementation needs to react as expected when
used in the collection or service browser---see below.

Something else to keep in mind is that not all resolvers are
browseable. Playdar will of course let us know which are browseable
and which are not. For example, the last.fm backend probably is not.
That's because there's no way to get "all" the tracks from the last.fm
API at once--it's an on-demand API that is based on searching. So the
last.fm full-track resolver (for example) could be search only.

So what I recommend is something like this:

* The playdar collection shows up as a collection in the CollectionBrowser.
* Browseable services are always shown fully in the playdar
collection, merged together (so the user gets the feeling of browsing
a normal collection)
* When the CB is filtered, the Playdar service can now query all the
resolvers to get search results. It can populate the result tree with
search results---even if these tracks come from resolvers that were
not showed before (because they are not browseable).

This way the user browses all the available tracks, and when he looks
for a specific track, sees any tracks that playdar can match for
it---all without having to mess with resolvers and showing what where
when how :)

Thoughts?


-- 
_____________________________________________________________________
leonardo.franchi at tufts.edu         Tufts  University 2010
leo at kdab.com                                 KDAB (USA), LLC
lfranchi at kde.org                             The KDE Project