Colin Guthrie wrote:
David wrote:
* dynamic lists/views (heirarchies/random/mood/suggested)
Yes. Random probably the odd one out as this could be left to the client application. As for that matter could the suggested tracks. The MetaLibrarian could just act as an aggregator for the raw data in relation to playcounts/skipcounts/score etc. but it could be left up to the application to actually use it?
By this time I'm thinking of the architecture around ML.
A service layer/area seems an obviously non-core and modular way to go.
If some services store static lists then fine - others may store parameters for algorithms like : genre or bpm driven 'random'
Because they're modular you just write a list generator and advertise it to clients - then *any* client can take advantage and not have to write their own
The core thing is you say 'give me a list of lists' then 'next 5 from list X'
X is just a name in the list of lists - the client doesn't care what _kind_of list.
I'm not saying ML delivers all this - just that when anyone writes a playlist service, it can be used by any app.
ML is the framework.
* stream/serve files? (probably not initially but if you want to do RPC type things then why not provide the raw data aswell?)
No reason not to I sps. But this may be better achieved by writing a closely linked companion DAAP server rather than reinvent that particular wheel? I'm open to further thoughts on this one.
Indeed. I was thinking about clients that were too dim to have full blown nfs/smb setups. My phone over bluetooth maybe... (one day - the point being not to constrain the design yet)
* Management * ui/api to create lists * ui/api to create dynamic lists * image grabbers for albums etc * lyric grabbers ... * FreeDB access? * file management (ie rename/move mp3s)
To be honest, I'm not immediatly convinced by the "ui" requirement. I was kinda thinking that the API would allow client apps to create their own UI to control this. Keeps the project in it's place and doesn't "steal" functionality from the applications that it wants to integrate with it.
More architecture layering.
I'm not saying ML delivers this either - you're dead right that others do this stuff - but the ML framework will ensure that when a playlist manager creates a view/playlist, Myth can use it. The intention is to understand what doesn't need doing.
Myth's frontend is a crap place to browse and drag'n'drop lots of music into playlists - sure you can do it but it's not nice.
Mythweb is a step in the right direction but really something like anarok with a full gui is the place to do a full blown playlist manager.
Then Myth can do a very basic editor and any other conforming manager (including mythweb) can do playlist editing.
Image/Lyric/Bio/Reviews grabbers would all be good. Probably linking to the MusicInfo package which already has this functionality :) (I think that's what it's called. Prokyon3 uses it).
What other solutions are there? * Amarok * madman * xmms * taglib
Taglib is particularly interesting as it aims to be a low-level API in the same sense as MetaLibrarian.
Yes I was secretly thinking that MetaLibrarian would either link against or swallow up the TagLib sources in some capacity.
and Taglib itself makes a point of being agnostic and having no onward dependencies.
I think ML may fit well conceptually into the Taglib/KDE ethos...
It is well placed to provide a simple upgrade route if you can offer the abstraction required by eg Amarok. (I wondered about slicing Amarok's DB system off - it already supports both mysql and sqlite so I expect some abstraction there. It may also be a suitable candidate for working the metalibrarian abstraction layer idea. Finally it may also provide a nice gui for later... It is written in Qt so it may be a place to grab lots of good code from even if there's no immediate Amarok/Myth marriage :) )
Yup that too is my underlying hope. I've not looked too closely at the Amarok source (just a few simple CVS backports for Mandrake patches), but I am hoping that it would be a reasonably simple process to integrate support. It would be quite a substancial change for Amarok tho' so would need the full support of their developers.
True.
I'm really liking the feedback I've received so far which has mostly been cautiously optimisitc. Most people seem to like the general concept, although are quite rightly concerned with how hard it will be to get others to support it. I guess a bit of pre-development marketing with other dev lists may help help gauge the general feeling?
What about prototyping with taglib's oo model and the architecture above, seeing where that goes.
Maybe look to Amarok's design for ideas.
Then see about getting a strawman design up for comment?
David
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
