Hello list!
So, I was involved in a discussion with theefer and anders_ on IRC the
other day about propdicts and source preference. Two issues arose and I
didn't really understand the consensus on either of them. So I'll ask
again on the mailing list so perhaps someone has the time to write a
more detailed response and I can ask more detailed questions.
1) Unifying propdicts and dicts. Anders says move source preferences to
the server side. I guess that means a client will only ever receive
plain dicts?
Actually, I think maybe I understand this one, but it leads into
question 2 below.
2) Current source preference is ok, but it has many weaknesses that are
showing up in more and more places. The question is, how can we improve
source preference so that all the information we need is easily accessible?
I *think* the consensus was to make the server understand more advanced
source preferences, like property-specific preferences. But we need way
more than that to get the information we need.
Let's use my fictional client, UberClient, as an example to illustrate
how mediainfo should be made accessible:
* Info in various playlist files is generally less accurate for title
than ID3/vorbiscomment/whatever, but not totally useless. UberClient
knows this and lets users choose whether they'd rather see title from
tags or from the playlist while keeping normal source preference for
everything else.
** This can happen two ways: 1) global tag-specific source preference or
2) per-entry tag-specific source preference.
* Cuesheets are great for people like me who listen to a lot of
electronic mixsets. I can tell you who made almost any song in a mix and
what the title is. UberClient loves electronic music fans, because it's
the best kind of music. So UberClient implements a treeview in its
playlist window. Single files that have various subentries are
expandable to show "artist - title (duration)" of the songs that make up
the mixset:
+ Paul Oakenfold - Voyage into Trance (72:00)
Trancemission - Genetic (6:00)
Sly-Ed - Man with No Name (6:00)
Aliens - Total Eclipse (6:00)
Teleport - Man with No Name (6:00)
Superbooster - Infinity Project (6:00)
Wicked Warp - Mandra Gora (6:00)
Voyager III - Prana (6:00)
Ayahusca - New Moon (6:00)
Feeling Weird - Infinity Project (6:00)
Slinky Wizard - Slinky Wizard (6:00)
Fat Buddha - Black Sun (6:00)
LSD - Hallucinogen (6:00)
** The data for the main entry comes from its file tags and the decoder.
The data for its subentries come from the cue plugin and the segment
plugin. The subentries are really the only thing in the playlist, since
I've only done an addpls voyage_into_trance.cue, so the main entry is
fictional. The data for the main entry comes from the subentries and has
to be looked up from different sources.
Try to implement these features and you will have a rough time at the
least. This effectively begs two questions: 1) How can a client get info
from more than one source at once? and 2) How can a client specify that
it wants certain sources to be preferred for certain songs and certain tags?
The answer to both questions is that a client already can do these
things, except not easily. Ignoring collections for a second, there's
nothing wrong with propdicts except that there aren't really any
powerful ways to access the data on the client short of calling foreach.
Some methods like flatten(propdict, "source", &dict) to flatten a
propdict to a plain dict or value_t *lookup_with_source(propdict,
"source", "key") would make it easy to get information from any source
and perform lookups from different sources for any entry. Bring
collections back into the picture and we have a problem since
collections have no idea how the client's logic works.
I've been pacing the basement floor for a while now trying to think of a
sane way to solve these problems and I'm starting to think some bastard
child of service clients and coll 2.0 is the way to go. Match
collections and queries can both work as they do now and, additionally,
they can use comparison functions supplied by the client to provide
advanced source preference. Perhaps service methods can be generalized
to provide this functionality.
Propdicts and dicts will remain separate entities. Better yet, propdicts
should be upgraded with some better access methods on the client side.
Then every client can specify the preferred source for every tag of
every medialib entry.
It's almost 5:00 am here and this mail is already way too long and my
legs are tired from pacing and tapping nervously. If this email
generates some interest and people don't simple write it off as tl;dr,
I'll be happy to add more.
--
Dan Chokola
--
_______________________________________________
Xmms2-devel mailing list
[email protected]
http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
