Summer of Code: Draft of Playdar Proposal

[Leo Franchi]

On Fri, Mar 26, 2010 at 10:09 AM, Bart Cerneels <bart.cerneels at kde.org> wrote:
> 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.

What part in practice would be less good? And why would that be worse
than breaking the playdar/resolver mentality which is essential to
playdar? I don't understand your generic concern that this can't work.

> 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.

we could easily just add a spinner to the playdar collection header
item when it's got ongoing resolvers, I think.

leo



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