Summer of Code: Draft of Playdar Proposal

[Bart Cerneels]

On Fri, Mar 26, 2010 at 14:49, Leo Franchi <lfranchi at kde.org> wrote:
> 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?
>

It sounds very good in theory. I'm a bit worried that the practice
won't be so perfect though. Although I'm hoping it will because that
would be awesome.

This also removes the need to have playdar in Internet Services, which
we already determined is a good thing.
We do need to keep in mind queries can take a long time. So the user
needs to be made aware a query is ongoing. I have not seen such a
notification (spinner, "searching..." or any other means) in amarok 2
yet so I assume we don't have that.