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

[Nikolaj Hald Nielsen]

I will have to disagree with most of this on technical grounds.

The main reason I used the collection framework as the basis for the
services is that it allows a very great degree of code reuse that
would otherwise not be possible. For instance, the code to display the
tree view in the main collection and in the services are the same.
This allows for consistent behavior, look and feel to be maintained
without having to duplicate efforts. And I think moving away from this
would be a mistake. Actually, I only realized the point that this
would mean that services could show up as "just another" collection in
the main collection view later. I also think that many of these
collections need the service. For instance, the Magnatune and Jamendo
services are ( although they only achieved this state recently ) based
on "complete" collections that _should_ support the full range of
operations needed by, say, dynamic playlists, it still makes a lot of
sense to have a separate GUI that allows additional operation, such as
purchases, as well as showing additional information. And although I
might be in the minority, I really like being able to go to the
"internet" tab and have the content from different sources separated
out, instead of trying to cram everything into one big tree view (
which people are of course welcome to do, I just want the other option
as well ).

The thing about defining the difference between services and
collections I think should be done on a per case basis. All services
are collections, we just need to decide if they are complete enough to
be usable with regards to dynamic playlists and if it makes sense to
do so.

- Nikolaj

>  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
>
>
> _______________________________________________
>  Amarok-devel mailing list
>  Amarok-devel at kde.org
>  https://mail.kde.org/mailman/listinfo/amarok-devel
>