Re: metadatabase

Kristian G. Kvilekval wrote:
> On Tue, 2003-10-14 at 11:34, David Hough wrote:
> 
>>On Mon, 13 Oct 2003 01:24:32 -0400, Ed Sweetman <[email protected]> 
>>wrote:
>>
> 
> 
>>Gutting a lot of the old code and starting a new branch would indeed make 
>>a lot of sense. There appears to be large amounts of code that isn't used 
>>at all, or is replicated somewhere else. It would also allow large changes 
>>to be made without having to ensure compatability with old code.
> 
> 
> Please make sure nothing uses the code..   Cleanup is a good thing,
> we've managed to not have win32 buildable for over a year after
> the last "cleanup".  We are still trying to recover.

I considered win32 to be dead, and it was broken before i touched it. 
Nobody takes an interest in it until it's too late.  Plus, win32 is 
using a different compiler. Since many compilers in windows freely 
available and even not so freely available dont support c99 and whatever 
the latest C++ standard is called, changes to update zinf screw up the 
win32 build. Both should use gnu tools, the common code should be as 
strictly standard as possible and that's that.  I didn't accidentally 
clean up zinf and break the win32 build, I removed the win32 build 
altogether because it was part of the cleanup.  It's great and all to 
have zinf ported to other OS's but nobody actively developing zinf can 
maintain it and that means they cant respond to user bug reports and 
errors and that makes it a liability to releases.  It's not like you 
couldn't cvs co the win32 code, i was just trying to fix a problem by 
removing the code from the head source (and thus active) tree so 
developers didn't go on building it and giving reports on this or that 
error thinking it was actually up to date. It needs to be written so 
it's at least buildable in cygwin, then at least some amount of work can 
be started in bringing it up to date.


> 
>>>So yea, lets see some definitions and specifications on what a playlist 
>>>should be, why does it have to be different from a metadata manager and 
>>>  under what method should the UI be hooked into the whole thing and 
>>>anything else relating to it.
>>>
>>>to me :
>>>
>>>Playlist: human readable text list of streams playable to the the player
>>>Playlist Manager: container that creates a list in the player consisting 
>>>of translated playlist entries such that a UI can correctly display the 
>>>entries.
>>>metadata manager: container that retrieves, accesses, removes, and 
>>>possibly writes metadata related to lists of streams given to it.
>>>
>>>
>>>Playlist would be an object or array of objects private to Playlist 
>>>Manager.  Metadata manager would be inherited by Playlist Manager. Such 
>>>that say to get the current track to be played you'd have a call to the 
>>>Playlist manager like 
>>>playlistManager->getStream("file:///home/mysong.ogg"); Retrieving 
>>>metadata if available is taken care of implicitly by getStream by simply 
>>>calling this->metaManager->getStream("file:///home/mysong.ogg"); which 
>>>only accesses the database.  A separate update method can be used in 
>>>metadata Manager to update entries in the database as opposed to 
>>>researching directories for files and such and adding them to the 
>>>database.  These should be done explicitly by the user and not used when 
>>>simply reading the db for displaying a playlist.   etc etc.  Some 
>>>feedback would be cool.
>>
>>Personally, I don't reckon the playlist manager should be concerned with 
>>metadata at all. The playlist manager should be concerned with providing a 
>>way to move about in a playlist (next, prev, set index, etc...) and 
>>providing the player with a url for the current track.  The playlist 
>>manager should also provide an interface for manipulating a playlist (add, 
>>remove, move, etc...) that will be accessed by the playist editing UI.
>>
>>There is no reason why the playlist manager should ever need to know 
>>metadata about any url as far as I can see, so it dosn't make sense (to me 
>>at least) that metadata should be read through the playlist manager. As 
>>far as I know the player itself never needs to know any metadata about a 
>>track, it just plays it. The only place metadata becomes relevant is in 
>>the ui plugins, so why mix the metadata in with basic player 
>>functionallity (i.e. playling a playlist)?
> 
> 
> I certainly agree.  I prefer the playlist to manipulate a list
> of URLs and nothing else.   Both the player and UI can retrieve 
> needed metadata on demand.  However, There are a few utility functions
> that don't seem fit elsewhere (i.e. total playlist time).
> I certainly don't want the playlist to cache metadata.

let me clarify:

a playlist would be an object of streams, given in std::string URI 
format for instance.  stored in a plain text file.

Metadata is an object containing fields pertaining to a given stream. 
stored in a database type file.

a playlist manager is more than just a playlist, it basically acts as a 
backend to the playlist UI.  This means it controls both the metadata 
manager (separate object i'll explain later) and the playlists and gives 
all sorts of features involving the two.  This means the UI's dont 
actually impliment any code except that dealing with the Interface.  The 
playlist manager inherits the metadata manager because the data in the 
metadata manager directly relate to the streams in the playlist 
manager's playlist.  It makes sense to keep that all coherent.  Your 
playlist manager gives you the ability to handle an arbituary number of 
playlists, methods for retrieving: full playlist time, shuffling, 
repeating, next stream, prev stream, adding, removing, clearing, 
everything and anything to do with manipulation of the playlists and 
retrieval of data related to the streams zinf plays.

Personally, I dont think zinf should be able to write to the files, it's 
a security risk and really has nothing to do with a "audio player" but 
since it's a requested feature by some, this I believe should be handled 
with the metadata manager. These functions normally wouldn't be accessed 
by the playlist manager so you'd call them directly with something like, 
playlistManager::metaManager->writeData("streamname",data); where data 
would be a MetaData object containing all the fields the user has 
specified etc etc.

The MetaData manager is just an object that does the database data 
retrieval and gives the playlist manager a simple way of accessing that 
data for UI use. It really shouldn't be anywhere outside the playlist 
Manager.  There isn't any reason why the rest of the player would need 
to see it. Having everything behind the Playlist Manager's api makes 
everything much more simple and easy to follow.

I rather prefer having the playlist manager take on all the duties of 
deciding what to tell the input system to play and what to allow the UI 
to display regarding the stream.  I think it concentrates all that code 
in one spot in zinf and allows programmers to more easily optimize the 
whole process and it gives all UI's equal access to features.


And just to be clear, i'm talking about a manager of playlists, not the 
playlist objects themselves.  I agree they should be std::string's of 
URI's, I just think the manager should be _THE_ api that the player uses 
to do anything related to the streams the user selects up to actually 
opening the files. And i think it can do this without being bloated or 
unweildy.




> However, we should still discuss the concept of recursive playlists
> as I alluded to in my previous posts.
> Here the base playlist type should simply be a list of URLs.   The
> player and the UI should be responsible for sensibly
> expanding recursive playlists.

I like the idea of dynamic playlists, it seems novel (unless i'm missing 
your inspiration for it).  I dont like relying on a UI to do anything 
but UI work though.  Rendering the expanded playlist should be the UI's 
job but actually creating the expanded playlist should be the job of the 
playlist manager.  Why should a major feature of zinf be only available 
to GTK land if say that's all the developers care to impliment it in? 
Why make it harder to port to other systems when there is always this 
arguing about remaining portable.  I dont believe there is any 
non-toolkit specific UI code in zinf unless it deals with starting up 
the UI thread, so I dont see how the UI's should be left doing anything 
but Input/output to the user and player.




> 
> 
>>I reckon the metadata manager should be completey seperate from the other 
>>base functionality of zinf as all it is doing is providing data to 
>>possible UIs, it is never actually used to play tracks. This is also part 
>>of the argument for not loading the entire metadata database at startup in 
>>the base section of zinf as there is no guarentee that it will be actually 
>>needed by the UIs, although it is highly likely.

Loading the entire database is cheaper than loading it little at a time. 
  You could not load it at all or just query the database per track in 
the current playlist, and either way on a newer computer this wont be 
noticed at all.  but on older computers where the proponents to the 
"delayed reading" of the database argue their method is better, I 
believe it actually eats more clock cycles by having to have the 
harddrive go back to the database to read more of it rather than taking 
advantage of the multi-block sequential aspects of the hdd's buffers and 
reading it all at once.  It's just faster that way, even though you take 
the hit all at once, it's all while the program loads anyway, not in the 
middle of a stream playback or something.  And besides, the error that 
the whole idea was cooked up to fix has long been fixed and was found to 
not be a problem with the size of the database at all, but rather a bug 
in zinf.

Metadata manager is completely separate as i mentioned above, it just 
happens that it can only be accessed through the playlist manager.   You 
could have them separate of course.  But that is doubling every query of 
a track since your UI is likely going to want to display metadata info 
as it displays the trackname and such.  Whereas your UI can do this:

vector<MetaData> playlist;
PlaylistManager->loadList("someplaylist.pl",&playlist)
That single command gives you all the metadata fields and the URI for 
every file in the playlist.  But manipulation of the playlist via the 
playlist manager is still done with simple std::string commands.

PlaylistManager->removeTrack("file://somefile.ogg");
PlaylistManager->curtrack("file://somefile.ogg");
PlaylistManager->searchTname("whatever",tempList);
MetaData queryTrack;
PlaylistManager::metaManager->updateTrack("file://somefile.ogg",&queryTrack)

etc etc.  The UI deals with a local copy of the playlist. As it 
generates the visual representation of the playlist it just iterates 
through the vector grabbing all required data and it's done.  It can 
dynamically add insert, remove, relocate all elements of it's list with 
simple strings

I mean, yes basically you could have the UI live off of just having a 
vector of strings containing the mirror of the playlist manager's 
currently loaded list of streams, but think about all the function calls 
the ui is going to have to make when manipulating even a fairly regular 
number of files.  Or the problems of juggling two lists around, one of 
the metadata and one of the names and then having to make calls to each 
of their own api's separately.  How to deal with one failing but not the 
other  etc etc.



> 
> Yes!  I hope eventually to completely disassociate the music/metadata
> browser from the player as they accomplish different goals. I think they
> should communicate through some sort of messages rather than direct
> calls.

I dont believe the player should even have a metabrowser system. This is 
the job of a completely different program.  We should read the metadata 
already there and this data is directly related to the streams handled 
by the playlistManager/musicbrowser.  They shouldn't be the same object, 
but they really have little reason to be accessed independently.


> The metadata systems could then be used independently by each. 
> 
> 
> 
>>Anyway, thats just my opinion, feel free to pick holes in my reasoning if 
>>there are any.
>>
>>David




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php