Summer of Code: Draft of Playdar Proposal

[Bart Cerneels]

On Fri, Mar 26, 2010 at 04:26, Andy Coder <andrew.coder at gmail.com> wrote:
> On Thu, Mar 25, 2010 at 1:06 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>>
>> I do think however that in this specific case, the best playdar
>> implementation will be a Collection and one that doesn't require
>> custom UI's. In general good integration into the app will always be
>> higher quality and nicer to use then something that feels hacked in.
>>
>
>   The trouble I run into in the service vs. collection discussion is
> spelled out in the UI (and I think you mentioned it earlier);
> Collections are 'local sources of content' and Services are 'internet
> sources of content'.  Where Playdar actually fits here isn't obvious,
> since a Playdar track can be either local, on the internet, or remote
> on a smaller scale.  Still, if it can be implemented satisfactorily as
> only a Collection, then I agree it makes sense to avoid the custom
> UIs, would rather avoid them myself (in general), and appreciate that
> what I think is a particularly fun design question has sparked this
> much debate.
>
> On Thu, Mar 25, 2010 at 9:40 AM, Maximilian Kossick
> <maximilian.kossick at googlemail.com> wrote:
>>
>> It is not an either/or decision. One could write a custom GUI for the
>> service, and add a simple "Show in collection browser" to enable the
>> collection there. One can do the same today manually by overriding the
>> CollectionStatus in amarokrc.
>>
>
>   This point inspired an analogy that I think does a decent job of
> illustrating the merits of a more involved implementation:
>
>   When school's in session, I work at the Dept. of Music library.
> All of our recordings are kept behind the circulation desk, and
> patrons can check them out only for use in the listening room.  Since
> patrons can't just walk through our selection, they search the online
> catalog, where they have the option to search only OWU, CONSORT (OWU +
> 4 other schools), or OhioLink (CONSORT + most other
> colleges/universities in Ohio).  If we have the recording, they walk
> up to the counter and ask for [LP/CD/DVD]#XYZ, and if it's in another
> library, they request it and it shows up at the counter just like any
> item we have, (it just takes a bit longer).
>
>   In case it makes the analogy clearer at this point, the patron asks
> for a recording (query), we get it by some method (resolver), and
> deliver it to them in a consistent manner across all sources (result).
>
>   Finally, patrons can ask for a reserve collection.  This collection
> is still listed in every catalog it would be normally, and items in it
> may belong to any number of libraries, (some user selected subset of
> all available content).   However, each member of the collection is in
> a single location so that the patron can see each item by
> performer/album name and quickly find the same item again and again.
> Any given patron, at any given moment, is only really interested in a
> relatively small subset of the recordings that we can obtain, but need
> to be able to find any recording through a query.
>
>   When I thought about this, it occurred to me that I really don't
> want to see every track available for download or full-length preview
> on last.fm, as if it was a local collection, on a regular basis (maybe
> just once, it would be cool...), but I would like such a view for
> tracks on a local network, and probably a subset of last.fm (artists
> connected to the independent dark electronic music group, for
> example).  However, If I'm looking for something that may or may not
> be a part of that collection, I want to be able to ask if it's
> anywhere in the catalog, and probably have the option of keeping in
> reserve.
>
>   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.

Bart