[GSoC Update] Playdar Collection: Week 1
Andy Coder
andrew.coder at gmail.com
Wed Jun 2 19:09:50 CEST 2010
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.
- 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
More information about the Amarok-devel
mailing list