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

Nikolaj Hald Nielsen nhnfreespirit at gmail.com
Tue Apr 1 17:42:32 CEST 2008


>  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.

>  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


>
>  Max
>
>
>
>  >
>  >  On Tue, Apr 1, 2008 at 3:49 PM, Maximilian Kossick
>  >
>  >
>  > <maximilian.kossick at googlemail.com> wrote:
>  >  > On Tue, Apr 1, 2008 at 3:25 PM, Nikolaj Hald Nielsen
>  >  >  <nhnfreespirit at gmail.com> wrote:
>  >  >  > One more thing. Please test  if you think the filtering in the Ampache
>  >  >  >  service is a bit more sane now. It turns out that the main issue was
>  >  >  >  actually the expression parser emitting blank elements when a level (
>  >  >  >  such as artist:foo ) was specified.
>  >  >
>  >  >  Actually, that's not the main issue. Try the following searches, and
>  >  >  you'll see what i mean:
>  >  >  12 sto
>  >  >  sto 12
>  >  >  abc club
>  >  >  club abc
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >  >  - Nikolaj
>  >  >  >
>  >  >  >  On Tue, Apr 1, 2008 at 2:58 PM, Nikolaj Hald Nielsen
>  >  >  >
>  >  >  >
>  >  >  > <nhnfreespirit at gmail.com> wrote:
>  >  >  >  > actually... seeing that it filter values should not be set for levels
>  >  >  >  >  that are not on the collection, I guess the AND's and OR's are from
>  >  >  >  >  somewhere else... Anyway, another possible benefit of having these
>  >  >  >  >  values defined like this is tat we would be able to issue a small
>  >  >  >  >  warning or message if the user enters an invalid filter for the
>  >  >  >  >  collection he is looking at.
>  >  >  >  >
>  >  >  >  >  - Nikolaj
>  >  >  >  >
>  >  >  >  >
>  >  >  >  >
>  >  >  >  >  On Tue, Apr 1, 2008 at 2:50 PM, Nikolaj Hald Nielsen
>  >  >  >  >  <nhnfreespirit at gmail.com> wrote:
>  >  >  >  >  > On Tue, Apr 1, 2008 at 2:38 PM, Maximilian Kossick
>  >  >  >  >  >  <maximilian.kossick at googlemail.com> wrote:
>  >  >  >  >  >  > Why not simply drop invalid filter values inside the querymaker
>  >  >  >  >  >  >  implementation? the result would be the same, but client code does not
>  >  >  >  >  >  >  need to know about all this stuff->keeps the API smaller. The problem
>  >  >  >  >  >  >  with your implementation is that we'd have to change that enum and all
>  >  >  >  >  >  >  client code if we add new filter values. Google-esque filters work for
>  >  >  >  >  >  >  all metadata in A1, not just for those few taht are implemented in
>  >  >  >  >  >  >  addFilters() so far.
>  >  >  >  >  >
>  >  >  >  >  >
>  >  >  >  >  >  Hmm.. I was wondering how we were going to handle all the stuff thats
>  >  >  >  >  >  not included in those values. Dropping filter levels in the QM is what
>  >  >  >  >  >  I have been doing so far, the issue is that in some cases it causes a
>  >  >  >  >  >  rather large amount of excessive calls to beginAnd/Or and endAndOr
>  >  >  >  >  >  which, especially for QM's that generate SQL queries results in a
>  >  >  >  >  >  unreadable mess of "OR ( 0 OR ( 0 ) ) AND ( 1 AND ( 1 ) )..." which
>  >  >  >  >  >  wash starting to greatly annoy me.
>  >  >  >  >  >
>  >  >  >  >  >  One argument that really favors this approach is that it will make it
>  >  >  >  >  >  possible to only present sane filter options in the filter builder
>  >  >  >  >  >  dialog.
>  >  >  >  >  >
>  >  >  >  >  >  - Nikolaj
>  >  >  >  >  >
>  >  >  >  >
>  >  >  >
>  >  >
>  >
>


More information about the Amarok-devel mailing list