Re:Re: Requirements composed

> Message: 3
> Date: Sun, 26 Oct 2003 17:16:42 -0500
> From: Ed Sweetman <[email protected]>
> To: [email protected]
> Subject: Re: [Zinf-devel] Requirements composed
> Reply-To: [email protected]
> 
> Ralf Engels wrote:
> > Hi,
> > I have written all the requirements together and added technical 
> > requirements where usefull.
> > Sadly there where much discussions about "how to do it" when the "what 
> > to do" was not fixed.
> > So, I would say that we should agree first on the requirement list and 
> > then someone can propose a design (based on the current design).
> > 
> > So, here goes the list:
> > 
> > Requirements for Playlist handling in zinf.
> > Sub-requirements are denoted with a point e.g. 3.1
> > Technical requirements are with two point 3.3.3
> > 
> > 
> > r1. there shall be a list with songs
...
> > 
> > 
> > Playlist item requirements
> > r101. the URI shall be the unique identifier of an item. URI is full 
> > qualifyer like file://hallo.mp3

> completely ignores the fact that i can add the same track twice in the 
> playlist.  How is the URI supposed to be unique for that? Are you going 
> to make zinf not support multiple iterations of the same track? That's 
> stupid, not in just my opinion, but just about every player i've used 
> allows multiple instances of the same track name.
> 
> Two tracks
> file:///this/is/another/track.mp3
> file:///this/is/another/track.mp3
> 
> How do i tell the playlist to remove the second one if i just do things 
> like playlist-manager.remove("file:///this/is/another/track.mp3");
> 
> You cant. URI's are not unique in the same branch.

Can you spell URI? Unique Resource Identifier. It is unique.
Of cause the list can include two times the same track but it is THE SAME
TRACK.
The same means "they are equal".

So, please what is so stupid about this, why are the same URIs not unique
and what is a branch?

> 
> > r102. the meta data of the item shall be determined on demand
> > r102.1 No data shall be duplicated.
> should be specified where this occurs.  You're not allowed to pass 
> pointers back to the Ui so obviously, the Ui is going to have to copy 
> the data in the playlist manager. I believe the playlist should recieve 
> pointers since it makes no sense to copy that data but it should be in a 
> read-only manner.  Likely though, that wont be feasible.
> 

The message has to be self contained. 
In the current implementation a playlistitem can be deleted while the
pointer is still in a message. 

I am in favour for just sending messages "something has changed" but this is
a technical requirement and not the scope of this mail.

> > r102.1 (logical extension) meta data of items with the same URL shall 
> > not be doublicated
...
> > 
> > 
> > To be clarified
> > r104. It should be possible to read metadata from various sources
> > (what sources are meant)
> 
> files, online databases.

How can you identify what meta-data to read? Can you please expain to me in
detail how this should work and what the benefit for the user is?

> 
> > r105. Metadata should only be read from an external source on demand
> > (why, what is an external source?)
> 
> external is outside the database.
> 
> > r106. It should be possible to do searchs on cached metadata
> > (search for what, what for?)
> > 
> 
> search for any particular metadata field, for use in the UI.
> 

This seems to me more a UI requirement and not a playlist specific. Anyway,
I will add this to the requirements.



-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/