Re: metadatabase

On Mon, 13 Oct 2003 01:24:32 -0400, Ed Sweetman <[email protected]> 
wrote:

...
>
> Zinf in itself is Ugly, unwieldly, and bloated with unused code that's 
> been forgotten about.  Adding this new system on top of that is just 
> doubling your work and slowing the progress of getting the new system up 
> to par.  I think you need to tear the old system out completely, call 
> this a new new branch started at when the new system was committed 
> (basically breaking zinf anyway) and continue development that way. 
> Win32 can either continue on at the old branch or decide to port the 
> makefiles to use libboost for win32.  Technically, there should be only 
> code ommissions that need to be done in win32 land as all the new mdb 
> code is completly portable code and should reside in a non-arch specific 
> location in the zinf fs.  I like the idea of less and less arch specific 
> code in zinf's base system but changes in the UI not being compatible 
> with win32 are unavoidable.  Win32 has gtk2 libs, it would be easier to 
> jump over to use that than continue to worry about keeping UI after UI 
> up to date, it would be just as stable.
>
> You'll get no where fast if you wanna keep everything working all the 
> time.  Actually you'll likely go backwards. Windows NT and Windows 9x 
> existed side by side, people in win9x couldn't get the benefits of NT 
> until they moved to it and the programs they used were ported to it. The 
> point is you can have the current pre-new-mdb zinf as that branch, 
> compatible with windows users and all, and have zinf 2.5 as the dev 
> branch on the road for say...2.6 or whatever.  Either way, 2.5 doesn't 
> have to "work" but it should be a the correct starting point for the new 
> mdb code, and that means tearing out the old code everywhere it exists. 
>   While you're at it, tear out every other obscoleted function that 
> hasn't been removed for fear of reverse compatibility too. If you get 
> them all zinf would probably be half the code size it is now. something 
> like that.

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.

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

Anyway, thats just my opinion, feel free to pick holes in my reasoning if 
there are any.

David

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


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