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

[Ian Monroe]

On Tue, Apr 1, 2008 at 10:42 AM, Nikolaj Hald Nielsen
<nhnfreespirit at gmail.com> wrote:
> >  The expression parser did not change from 1.4 at all, you added the
>  >  calls to beginAnd or beginOr to addFilters.
>
>  Even so, the expression parser ( src/expression.cpp ) was badly broken
>  for some reason ( maybe it had just been automatically ported from Qt
>  3 to 4? ), and though I though I fixed it a while back, It still had
>  some issues left regarding AND, OR and "'s that I _think_ I finally
>  got fixed today. The calls to beginAnd() and friends are are added to
>  the CollectionTreeItemModelBase and not to the expression parser.
>
>  >  yes, i disagree, because an ampache server should imo be queried by
>  >  smart playlists (as soon as we get around to implementing those). And
>  >  the current design (which makes sense imo. otoh, it's my design, so
>  >  that's not really a surprise) is that smart playlists will query all
>  >  collections that collectionmanager knows about (generally. querymaker
>  >  has some methods to control this in more detail, but that's not
>  >  actually implemented anywhere yet. I'm not actually sure if that
>  >  feature is necessary). Amarok is very much about smart/dynamic
>  >  playlists, and it should be able to use as many collections as
>  >  possible as source for smart playlists. The idea is
>  >  network-transparency of music: it should not matter where the music is
>  >  stored, Amarok will be able to play it just like local music. And part
>  >  of that network transparency is the ability to use smart playlists to
>  >  play songs from Amarok. I still do not get what you think the
>  >  conceptual difference between Ampache and DAAP is. It's simply remote
>  >  storage for music. Nothing more, nothing less. Or do you think that
>  >  DAAP collections should not appear in the collection browser either?
>
>  Then we obviously have very different goals for the Ampache service at
>  this point. I worked with Vollmer to come up with a simple API that
>  would allow us to browse and stream music from Ampache within Amarok,
>  and we achieved that, I use the Ampache service every day and is quite
>  happy with it. We purposely made the API very simple so it would be
>  easy for other projects to implement, which they already have. I agree
>  that using music from Ampache in Smart and dynamic playlists would be
>  nice, but it is quite simply not something I have actively worked
>  towards when initially implementing the service and to be honest, it
>  is not something I am motivated for doing at the moment.

I kind of assumed Ampache would have smart playlist capabilities. Like
Max said, Ampache really is solving the same problem as DAAP. I would
really consider it much more important then Uploading, since it's
about harmonizing Ampache with the rest of Amarok as opposed to adding
a new feature.  (Downloading is pretty much trivial, it took me half
an afternoon to add it for DAAP back in the day).

Plus I really want Ampache music in my Dynamic Playlist. :)

Given the complexity of setting up Ampache, setting up an SFTP or FTP
connection isn't much more work, so in-Amarok uploading isn't even
really adding a new feature to Amarok or Ampache, just making things a
bit easier.

>  >  Regarding the capabilities of AmpacheQueryMaker: what about extending
>  >  the Ampache API? vollmer already said that he is not opposed to
>  >  extending it within reason. And queries for more than one string at a
>  >  time are a very reasonable request in my opinion. A lot more than that
>  >  is actually reasonable, one just has to figure out a way to extend the
>  >  ampache API so that vollmer agrees with it. Otherwise i'm really
>  >  wondering what the point of that GSOC project is. Adding http file
>  >  upload from Amarok to Ampache? 4 months for that?
>
>  Again, for me, personally, being able to up and download files is the
>  feature I would most like to see implemented as it is something  I
>  would use. This might not be very objective, built it is what keeps me
>  motivated, and it is the project that a student has actually applied
>  for. I am as such not opposed to extending the Ampache API ( _IF_ it
>  can be done in a sane way that does not make people who just want to
>  list and play stuff from a simple interface want run away screaming ),
>  and making the Ampache content integrate perfectly within Amarok, but
>  again, it is not what I am most motivated for doing first. If someone
>  else wants to pick it up, that is fine with me. We also have time now
>  to write up another project idea and see if there are any takers.
>
>  As for the size of the upload project, according to the discussions
>  between Vollmer and the student, this is apparently going to be quite
>  a task as the upload method has to work on many different hosts where
>  a large number of people has their Ampache server set up, I also think
>  there is quite a bit of work needed in Amarok, especially if we go for
>  full synchronization support.
>
>
>  >  And why is this e-mail not on amarok-devel?
>
>  Because it grew out of a discussion on the commit list, and since I am
>  an idiot a this "reply/reply all" stuff it got thrown off track at
>  some point. That _should_ be taken care of now.
>
>  - Nikolaj
>