Russell Penney wrote:

>I will try to dig up what I had (it has been a while) but real-life things
>are taking precedent at the moment. 
>
>I am not a "real" programmer (this is a hobby) so what I was really after
>was some mentoring...well a person(s) who I could pass stuff to and have the
>error of my ways pointed out, preferably in a supportive way ;)
>
>I have said this before, I am happy to do the work but I need help doing it.
>
>Obviously a good design is important and I feel there is too much "just do
>it" and not enough "lets plan this". I think multimedia and file handling in
>general are areas that shouldn't just have a solution thrown in but need to
>be carefully thought out.
>  
>
I agree totally. We need some guidelines of how stuff should be 
implemented. These classes are kind of a
extension of the collection classes and need some structure to be 
graspable. And they have lot's
of code they can share.

>So to get started here are some random thoughts in no particular order:
>
>Have abstract classes for each fundamental type of media:
>Image
>VideoStream
>AudioStream
>  
>
I like this. Image is a confusing word in Smalltalk, maybe picture 
instead . A midi file is not really any of this, but it should open in 
score player.

>That class defines the minimum interface to each type.
>Sub-types can have other features but there is a minimum of functionality
>for each class to be compliant.
>Compliance means that the Codec has passed a minimum set of tests and is
>added to an official extension package.
>
>*Player*
>Each fundamental type has a player capable of presenting the data of the
>instance on a particular interface. Audio would really only need one (the
>sound card) although the potential is there for packages for network
>broadcast, HTPC systems, multi zone, etc.
>Think of these as a data sink perhaps. It's the object that pulls data in
>i.e. it's the controller.
>The Sink would request data in a format that can be negotiated between the
>sink and the source of the data. There would be several "default" standards
>that are particular for each Media. I.e. Audio has each channel data
>interleaved or in a separate Array and/or 16 bit or 8 bit or 32 bit.
>Basically each standard transforms a set of data to the native format of
>that Media Sink.
>
>
>Each Media and Format can really be broken down into:
>*a container of pixel data
>*a container of containers of pixel data (video)
>*a container of PCM values
>*a container of some other fundamental type i.e. characters (String), UTF, 
>*a container of one or more of the above containers
>
>*File Formats or Really Byte Stream Formats*
>They must be able to detect the signature of many different byte stream
>formats to "parse" the correct one.
>
>Perhaps? Use MEPS pattern to parse Formats. Another instance method
>(to:startingAt:) could be used to emit a byte stream representation.
>
>CodecFactory holds the mapping of extension and keyword to classes that can
>encode/decode the format.
>CodecFactory newFromExtension: 'jpg' 
>CodecFactory newFromKeyword: 'JPEG' 
>CodecFactory newFromKeyword: 'ITU-123' 
>CodecFactory newFromKeyword: 'RFC1120'
>CodecFactory newFromMIMEType: 'image/jpeg'
>
>*Signatures*
>How do you identify a file (rather than something that has a MIME type) as
>being a certain type?
>  
>
This is tricky.

>*Methods*
>parse:
>parse:withMetadata:
>
>  
>
karl