Ampache service, was: Re: extragear/multimedia/amarok/src
ian at monroe.nu
Tue Apr 1 18:36:22 CEST 2008
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
> > 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
More information about the Amarok-devel