On Wed, Jan 21, 2009 at 05:05:43PM +0000, David Flynn wrote:
> On 2009-01-21, David Schleef <d...@entropywave.com> wrote:
> > It is, of course, important to provide code that makes it easy to
> > use the library. However, I think it's better to provide generic
> > parsing code and say "please modify this as fits your framework"
> > rather than provide a parsing API that might not fit.
>
> Indeed; however, again i am quite against dolling out all the parsing
> framework for people to implement blindly. It is complicated to get
> it absoloutly right and dealing with it in the library seems
> appropriate.
>
> NB, if low level access to the decoder is still required (which could
> return parse faults), that would be trivial and appropriate.
After some thought...
Obviously, the SchroDecoder API is a mess. If I had the option, I'd
simply ignore compatibility and fix it. The major problem, as I see
it, is that it *partially* does parsing, and does do either picture-mode
or stream-mode very well. Because of this, the state machine is too
complicated.
Ideally, I'd like to see:
- SchroDecoder that works on a picture basis.
- SchroParser that parses a bitstream into pictures
- automatic glue code in SchroDecoder that allows you to use the
decoder in bitstream mode
The main reason for this division is that a parser is more applicable
than just a front-end for a decoder, and having two implementations
(one separate, one as the front end) is begging for incompatibilities.
dave...
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Schrodinger-devel mailing list
Schrodinger-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/schrodinger-devel
