Ampache service, was: Re: extragear/multimedia/amarok/src

[Bart Cerneels]

On Wed, Apr 2, 2008 at 7:03 PM, Mark Kretschmann <kretschmann at kde.org> wrote:
> On 4/2/08, Nikolaj Hald Nielsen <nhnfreespirit at gmail.com> wrote:
>  >  My vision has always been to make as much content available to the
>  >  user as possible. Quite simple. My big mistake might be that I have
>  >  not really at any point taken smart or dynamic playlist much into
>  >  account, mainly because there has not been any. I think the difference
>  >  is that why you see the Ampache collection as an integrated par of
>  >  your music, I have so far just considered it an convenient way of
>  >  accessing music somewhere else. I am guessing your view is colored by
>  >  the DAPP collection which I btw have never tried or used.
>  >
>  >  As for thinking the proposals are weak, fair enough, but so far I
>  >  don't even think we have not even gotten to that discussion yet, as it
>  >  has so far always been about changing the projects to something
>  >  completely different than the proposals. For the record I would agree
>  >  that the Ampache one could use some more work, while I find the
>  >  Mp3Tunes quite good! It certainly matches how I would go about
>  >  implementing stuff, getting collection to collection copying up and
>  >  running, making Mp3Tunes up and downloading work, and using that as a
>  >  springboard/test case for looking at synchronization in general. I
>  >  would never try to design a framework in advance, and I have great
>  >  respect for you being able to do just that, but I have sen it fail in
>  >  real life way too many times.
>
>  I still don't understand in what way the two "visions" contradict each
>  other. Seem to me that complete network transparency is just an
>  extension of your design, so you wouldn't lose anything.
>
>  --
>  Mark
>

Allow me to chime in.

I think it's helpful to think of Services and Collections as to
separate things with different goals. A service is internet content
that is accessible but not fully integrated in Amarok. The full
integrated experience is reserved for Collections, with statistics,
querying and such, which are supposed to implement all that "added
value". As anyone who tried implementing a collection would agree, it
is hard work to create a "complete" Collection.

In the case of Ampache, I think it deserves an "upgrade" to a full
collection, querymaker and all. This is possible since we have
"control" over both ends of Ampache, thanks to vollmer. Ampache would
thus behave like the local collection and media device collections and
be shown in the CollectionBrowser. Considering how I've been using
Ampache: configured it only once and been playing music from it ever
since, it would make more sense if it was in the collectionbrowser,
not forcing me to start the service in the servicebrowser all the
time.

Since Nikolaj based ServiceBase on Collection we ended up without a
technical difference between the two from the developers point of
view. I'm not blaming him for that since the framework was there. I
would do the same.
But for the user there will be a world of difference: Services are
external, Collections are part of Amarok. Perhaps this can (or already
is) solved by making the Services TrackProviders (and
PlaylistProviders) instead of collections, separating the 2 in our
minds.

So I propose to define at which point a service would become a
collection and thus shown in the correct browser, it is a matter of
user perspective.

Bart