ok, so i've re-read your proposal
i'll play it back in my words and see if you agree (or ignore me, should you see fit)
Hehe :)
metalibrarian is a library
it reads and write metadata
this metadata can be attributes of "content" - name of artist, etc
it can also be attributes of the use of this content - last played, playlist membership, etc
this metadata can be stored in the files where possible (ID3) or separate (playlist)
the library can be an RPC into a server or it can be a wholly self-contained API with no server
would it be fair to say that it is an ID3 tag library extended with methods to read/write data outside the basic ID3 tags. the server aspect of it adds flexibility but as the files have to available on the filesystem, the extended metadata could be stored alongside the media it describes
if the library was based on or used an extension of an existing API then it could be a drop in replacement for that used in mythmusic.
did i get it now?
More or less that is a good summary.
I'll assume that when you say "ID3" you mean a generic metatag (e.g. vorbis comment etc.) too.
I'd also add that the data would be stored (or in the case of ID3 related information perhaps "mirrored" is a more accurate term) in such a way as to provide very efficient access and searching (e.g. in a database in much the same way as MythMusic/Amarok/Domo etc. do), so when you say "the extended metadata could be stored alongside the media it describes" this is technically true but would be inefficient in terms of querying etc.
Also, as the majority of music programs offer some form of hierarchical view to browsing a music collection, one of the main features I'd like to add into metalibrarian is the ability to setup a preferred stucture for this heirarchy (Myth offers some capability to configure this heirarchy just now and it works fairly well for the majority; Amarok also offers some degree of configuration). But everyone has their own tastes and one of the biggest complaints I hear is poor support for classical music tags. So I'd like to make a really flexible hierarchy config system that could use complex "if's" on the tags at each level e.g.
level1 = if tagnotempty(composer) "composer (artist)" else "artist"
level2 = "album"
etc.
(this syntax etc. it not even slightly thought out at this stage, but hopefully you catch my drift).
This script can be pre-cached in the database and supplied very quickly to any application that wants a hierarchical view of the music collection.
You could store several of these hierarchical configurations; call them "views" for the sake of argument. A really nice feature would be a Gnome VFS (virtual file system) plugin that allowed you to traverse these different view hierarchies as if they were normal files/folders (I think this is how VFS stuff works tho' I may have misinterpreted this!!).
I think when you say:
> if the library was based on or used an extension of an existing API > then it could be a drop in replacement for that used in mythmusic.
is a not quite correct. I think functionality wise it could be a drop in replacement for the database that drives MythMusic (mainly due to me having a fair bit of experience of MM's setup), but I doubt it would have a similar API to the functions/classes in Myth as it stands currently.
WHen I was talking about existing APIs etc. I was really just wondering if DAAP (or similar) could for the basis for exchanging the data, but I think Thor cleared this up for me in that it probably wouldn't be the best base (tho' this would not rule out creating a DAAP daemon that used the MetaLibrarian to make the music/metadata available to all DAAP clients).
Col.
--
+------------------------+ | Colin Guthrie | +------------------------+ | [EMAIL PROTECTED] | | http://colin.guthr.ie/ | +------------------------+
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
