[GSoC Update] Playdar Collection: Week 1

[Maximilian Kossick]

On Wed, Jun 2, 2010 at 7:09 PM, Andy Coder <andrew.coder at gmail.com> wrote:
> On Sunday, May 30, 2010 05:03:54 am Maximilian Kossick wrote:
>> On Sat, May 29, 2010 at 7:56 PM, Andy Coder
> <andrew.coder at gmail.com> wrote:
>> > Hey folks!  It's update time!
>> >
>> >   Although I'd been hoping to get some code written this week,
> I've
>> > mostly just collected pages of notes, scribbles, and sketches,
> but I
>> > did set up a proposed directory/file layout, (and the object layout
> it
>> > implies), which looks like:
>> >   in src/core-impl/collections/playdarcollection/:
>> >      PlaydarCollection.{h,cpp}
>> >      PlaydarQueryMaker.{h,cpp}
>> >      PlaydarMeta.{h,cpp}
>> >      controller/
>> >      controller/PlaydarController.{h,cpp}
>> >      controller/PlaydarControllerPrivate.{h,cpp}
>> >
>> >   Still missing here are places to provide capabilities.  It looks like
>> > other collections put these in their base directories, but my first
>> > thought was to have a capabilities/ subfolder.  Any opinions?
>>
>> A capabilities/ subfolder sounds neater. Don't forget to put your
> unit
>> tests into tests/core-impl//collections/playdarcollection !!
>>
>> >   Regarding PlaydarCollection, I think it makes sense to use a
>> > MemoryCollection, much like we do for DAAP.  What I'm not clear
> on,
>> > however, is where the populating of the collection should be
>> > implemented.  Is there a reason not to start the process from
>> > PlaydarCollection's constructor?
>> >
>> >   I expect PlaydarQueryMaker to use a MemoryQueryMaker to
> query
>> > the MemoryCollection, while asking Playdar to resolve queries
> and
>> > augmenting the results list with any results as it's informed of
> them.
>> >
>> >   PlaydarController implements an interface to Playdar that
> makes
>> > sense in Amarok/Qt world, so that we can initiate queries as Meta
>> > objects and wait for a signal that there are valid result URLs.
>> > PlaydarControllerPrivate is used like a d-pointer, and directly
>> > implements the functionality of the Playdar API, (status, resolve,
>> > get_results, and eventually something to fetch a collection's
>> > members).  This way, future API changes primarily affect
>> > PlaydarControllerPrivate, and the only reason PlaydarController
> itself
>> > should have to adapt is to add new functionality.
>> >
>> >   For PlaydarMeta, MetaStream may provide at least most of the
>> > needed functionality.  None of the Playdar result URLs that I've
> given
>> > to Amarok as streams so far have had any metadata troubles, at
>> > least.  There's the (extremely annoying if it happened in a
> situation
>> > where we new what track/artist/album to expect) behavior where
> a
>> > stream is initially a URL until it's playing/been played and the
>> > metadata has been fetched from the stream, but providing an
>> > alternate constructor would probably do the trick.
>>
>> You will definitely need to read track metadata using the Playdar
> API.
>> MetaStream will generally not provide metadata until the stream is
>> played. MemoryQueryMaker excepts all Meta objects to have the
> correct
>> metadata at all times.
>>
>> >   A more interesting problem to consider with PlaydarMeta is that,
> if
>> > Playdar has been stopped and restarted since a track was
> created,
>> > the playableUrl is no longer playable.  This is most noticeable if
> there
>> > are Playdar streams in the playlist, and the systems restarts,
>> > resulting in unplayable members in the playlist when Amarok is
>> > opened again. However, since it's likely that a new Playdar
> instance
>> > knows where to find the track, (since the old one did), we can
> get a
>> > new URL.  A 'Resolve' capability could be exposed through the
> right-
>> > click menu easily enough, but it makes more sense to me to do
> this
>> > automatically if we need to.  I'm not sure I can use the existing
>> > MultiTrack functionality for this directly, but the solution may at
> least
>> > be similar, using a 'Resolve' action as a fallback if the existing
> URL
>> > doesn't work out.
>> >
>> >   Finally, I noticed that JsonQt is in the Amarok source,
>> > (src/context/engines/songkick/JsonQt).  I'd like to use this, since
>> > Playdar responds in json and may accept it in the future.  Should
> I
>> > include it where it is now, or work out another arrangement, like
>> > moving it somewhere less component-specific?
>>
>> Move it somewhere less compnent specific please.
>>
>
> Any idea where to?  I thought shared/ sounded right initially, but
> JsonQt isn't used for utilities, which clashes with the README note in
> that directory.  I'm not sure if anything else seems appropriate.

I'd suggest a new top level directory, e.g. amarok/external, and then
put JsonQt in amarok/external/JsonQt. Create a README in it to state
that all external libraries that are needed in amarok's source tree
have to go there. Should make it easier to throw them out of our
source tree at some point.

Any other opinions?


>  - Andy Coder
>
>> >   For the next week, I'm planning on playing fill in the blanks with
> the
>> > above files, making more notes, possibly being a bit more
> intrusive
>> > when trying to get information from Playdar folks, and throwing
>> > together a quick little test with JsonQt and various JSON
> responses
>> > Playdar generated yesterday so I can tell exactly what sort of
>> > QVariants I can expect to be working with.
>> >
>> >  - Andy Coder
>> > _______________________________________________
>> > Amarok-devel mailing list
>> > Amarok-devel at kde.org
>> > https://mail.kde.org/mailman/listinfo/amarok-devel
>>
>> _______________________________________________
>> Amarok-devel mailing list
>> Amarok-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/amarok-devel
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>