Re: Re:Re: Requirements composed

Ralf Engels wrote:
>>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".
URI is universal resource identifier.

 From The Free On-line Dictionary of Computing (27 SEP 03) [foldoc]:

   URI

           {Universal Resource Identifier}



 From Hitchcock's Bible Names Dictionary (late 1800's) [hitchcock]:

   Uri, my light, my fire


 From Virtual Entity of Relevant Acronyms (Version 1.9, June 2002) [vera]:

   URI
        Universal Resource Identifier (WWW, RFC 1630)


that's from the unix dict command. I looked it up before i used it.


But the meaning of the word URI is besides the point.


How is my playlist manager or playlist supposed to know which instance 
of a duplicate track i want to move or remove if i'm just talking to it 
in URI's ...ie.  file:///some/path/song.mp3 ? I'll have two instances of 
it and with no other information, it has no way of figuring out which 
one i meant to manipulate.  And it does make a difference which one 
because say i had the two tracks in separate places of the playlist and 
needed them that way but had to move one of them.  What then? Will the 
player move both? move the one closest to the front or back of the list? 
There is no additional data to help the playlist decide which one i want 
to move.  So unless you're encoding an index in with the URI to 
differentiate duplicate tracks, there is no way to use URI's as unique 
identifiers in a playlist.  And if you'r encoding such indexes, there's 
no point in even bothering with URI's.  As there is no point in 
bothering with constructing everything around URI's in the first place 
since the program doesn't need to be able to read human readable track 
names in order to efficiently make those track names available to the 
user, and in fact as stated above, it's much less efficient and a 
hinderance to the program to do it that way.


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

in a playlist that has references to other sublists, a branch is a 
sublist, that sublist may also reference another sublist via zinf:// or 
another playlist file, in which case those are branches as well. The 
main list is also just a branch, it just happens to be branch 0.


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

yea, anything but the playlist manager directly controlling the player's 
playlist is illegal.


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

Well, to certain users who care about metadata (i'm not one of them), 
they may want to query an online database for the metadata that perhaps 
certain files they have lack.  So once the metadata manager scans the 
file for the required metadata, since it wasn't in the database in the 
first place, it queries the online database. It's a sequence of trial 
and errors until it exhausts its options or it finds the data it needs. 
  This of course would be time consuming so it would be a user specified 
option.

> 
> 
>>>r105. Metadata should only be read from an external source on demand
>>>(why, what is an external source?)
>>
>>external is outside the database.

and of course by external, i mean files and online databases.  Zinf's 
own database is considered internal and less of a performance hog.

>>
>>
>>>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.
The ui needs to be able to do a search for a metadata field, it cant do 
this on it's own.
If you imagine that the metadata manager is inherited by the playlist 
manager, then you can have a generic virtual search method that takes 
all varieties of searches based on some regex syntax decided later and 
based on that can search based on simple playlist attributes or if it 
matches certain types of regex, call metadata manager's search method 
with the string and return it's results.   This way the UI only deals 
with one method to do it's searching, instead of having to have access 
to two classes and decide when to call which class to do which search.

All of those specifics are of course of out scope.

> 
> 
> 




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