Re: Re: Zinf Status?

Ed Sweetman wrote:
> Robert Kaye wrote:
> 
>> On Fri, 2002-10-25 at 07:40, Ken Causey wrote:
>>
>>> I've been wondering how active this project is myself.
>>>
>>> http://sourceforge.net/project/stats/index.php?report=months&group_id=51494 
>>>
>>>
>>> is a little disheartening.  CVS commits have been steadily dropping
>>> since June.
>>
>>
>>
>> Then you better start writing some code, QUICK!
>>
> 
> hahahaha    here's a very early sneak preview of completely untested 
> code that's far from finished.  much more is still in my notebook.  No 
> more tests until next friday so i should be able to work on it a lot 
> this weekend


Heh, i'm changing things rapidly with the input system as i get ideas of 
better ways to do things.   Right now the Stream object is polymorphic 
to minimize any kind of type specific coding in the input subsystem.  To 
the input subsystem it should all look the same no matter if you're 
getting data from the cdrom / files / http / rtp / etc.  It creates a 
new object of the specific type upon starting the input subsystem.

I've decided that the sequence of creating the subsystems is good.  Big 
surprise eh?  It works in reverse at first, with the startup of zinf all 
of the subsystems are created from the output plugin's creation which is 
created from the UI. UI is a polymorphic class of the Zinf main class. 
Info is a little far away from being developed but suffice it to assume 
that a reference to Info is sent to all objects.  So once the UI tells 
the output object to play a file at a certain position (0 for example) 
the call carries down to the input subsystem.  It creates an object if 
one doesn't exist of the Stream polymorphic class. Say a zinfFStream 
object because the filename begins with file://.  If it already existed 
or now that it does it gets data.  Since the decoder subsystem called 
the input subsystem's get data method the decoder subsystem is 
responsible for reading the initial data from the file and determining 
if it's a supported codec.  It figures out which one it is and creates a 
polymorphic object of decode class which is the decoder guts for that 
codec.  It feeds the rest of the file data to it's decode method since 
that was what was called from the output subsystem. The output type is 
determined by the Info object at creation of the output subsystem but 
the outputType object is polymorphic.

In this manner it's transparent what kind of file, what decoder, and 
what output module you're using to play a file.  Making zinf extremely 
extensible.  I'm working on this right now as a compile time plugin arch 
but I dont think it should be very hard to make them into runtime 
plugins given the already polymorphic design and the independence of the 
  Input  subsystem from any individual kinds of objects it uses.  Only 
the base class of that object, as the program is coming along now, needs 
to know what kind of objects it can create are.  This design means 
binary distribution without compiling the main program for all available 
modules wont work.  That is just fine tuning though.



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en