being serious about the NG of zinf

As is known, i'm working on a complete rewrite of zinf. Why, how would 
this still be zinf if it's a complete rewrite and the current zinf has 
no documented specs? Well, it would be zinf by not just looking like 
zinf but succeeding in the goals that zinf has wanted to succeed in. 
This would be internet streaming, audio data management, low system 
footprint, and extendability. I'm always looking for more people who 
want to help work on and give input on this while it's still feasible to 
change the framework of things.  I'm talking about programming input, 
ideas of what datatypes should be used for what and what ways to code 
for this or that.  That would be really helpful.



Right now I'm opposed to using threads for the main player.
Threads could possibly be used in the situation where we're streaming or 
playing from the internet. This is because of a couple reasons. We could 
have a large output buffer which may make reading from the stream be in 
longer intervals than ip allows for timeouts, thus losing our 
connection. Also, for streams, we may miss packets during our requests 
for more data.
The only other time we need to think about threads is when adding files. 
  But this is an easy one, and an example that illustrates the objective 
nature of the new player.
I'll explain.  After making our selection we update the playlist with 
all the new filenames (if we selected files) and leave other data 
elements blank. We then create a thread and then move on to whatever the 
player is doing.  In that thread (if we selected a directory or 
directories we scan them and create a vector of strings containing all 
the files with types we can use) we construct an addfile object that is 
sent a vector of strings which refer to the name of every file we want 
to add upon construction and a pointer to the playlist.  The playlist is 
just a map with the key being the filename and the value being a 
delimited string containing all the metadata. The addfile wants to be as 
fast as possible so it asks if we have a database file, if so it opens 
the database and asks if the file is in there, if so it updates the 
playlist element with the data, otherwise it asks if it has a pipeline 
created, if not it creates one and calls the openStream method.  This 
allows it to read metadata of the filename and it then uses the 
closeStream method and if any metadata was found it updates the playlist 
element, otherwise it moves on to the next filename in the vector. It 
doesn't need to open the database or create a new pipeline for the rest 
of the files  in the vector and if all the files are in the database it 
doesn't create the pipeline at all.  It closes the database at the end 
and deletes the pipeline and when the thread closes it deletes the 
addfile object thus telling our ui it's ok to allow more files to be 
added by the user.  Whe n the main player opens a file for actual 
playing, we always read the metadata and update the playlist in case our 
database metadata is outdated, depending on settings  we will save this 
data to the database.
Heh, that looks a bit long to be simple but the length of the 
explanation is misleading.  The addfile object wouldn't be more than a 
30 lines with most of those simply being conditionals to make sure we 
aren't being  redundent.

Other than that, the pipeline is not going to be threaded.

In other areas of design, ideas such as the mapped strings for managing 
preferences are going to be put into use.  This makes querying and 
adding preferences extremely easy and fast as well as having a low 
memory footprint.  All plugins will maintain their own preferences with 
default values which are querier upon plugin loading and added to the 
player's pref list if needed and if any are added to the list, the 
config file is scanned for preferences again and if the added elements 
are found in it, it's given that value,prefs which do not already exist 
in the list are ignored.  This gives complete independence from the 
player to the module making it possible to distribute modules (plugins) 
without having the player's source be altered or recompiled.

The main source of all the info dealing with the player is the info 
object.  previously this was to be threaded but since i'm heavily 
against threading such a heavily used object, another simple locking 
mechanism can be done. Since the pipeline is serial, no simultaneous 
writes can be done but since the plugins may create their own threads 
and still read from the info object for data that the player may be 
changing in the meantime, we need a boolean member to info called lock. 
  At the very beginning of every method in info that queries data 
members is  while(locked) usleep(10); and if we are writing data 
directly after that while block is locked = true; and at the very end of 
the method or wherever we return, locked = false;  I'm thinking this 
will mostly help the UI subsystem since it may request to read current 
track info while the info object is copying what it's sent from the 
pipeline to it's own data members, leading to weird things being 
displayed.  Other than threads created by plugins, there is no other 
possible causes of races in zinf or possible deadlocks caused by our own 
program.

minimizing external lib dependencies is a large factor in making the 
player portable among not only OS's but archs.  Only plugins should have 
external library dependencies and that excludes input.  Input is 
probably the most arch and os specific parts of the player and becoming 
dependent on external code to handle input functions is a serious 
handicap.  For that reason input plugins should be self contained.  I do 
still have my doubts on how feasible it will be to not depend on libs 
for certain protocols in the input plugins so this is still debatable.

And foremost as anyone reading the list would guess, subsystems are to 
be explicitly forced to stay within the bounds of their subsystem. 
Everything in the decode subsystem (plugins included) do not access 
files/network streams directly nor do they output anything directly. 
They just decode data from the input buffer to the output and update 
info as needed.  Nothing is going into the main tree that does not 
conform to the pipeline specs and when the time comes no plugins will be 
recognized that do not either.

I wanna get all the details of what people would like to see and have in 
the next generation of zinf before things get too ingrained to change 
easily.  That way documents can be made for specifications and 
expectations and the player will work the way everyone wants it.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf