> From: [...] Russell Penney
> I was thinking along similar lines. Love the Squeak Codec source idea!

You heard it here first :-).

> My thought would be to have a "priority" of a Resource so 
> that you have a known order of codecs to try.

I have a pet hatred of priorities in a framework where anyone can add
their own codecs - you tend to get an arms race developing as developers
strive to put *their* codec first.  Treating the codecs as a set
prevents that.

If you have to have priorities, make it instead something like that
codecs return a set of symbols listing features they've identified in
the stream with some cost function for decoding the stream (expected
bytecodes per megabyte or some similar objective measure).  That way you
get extra information: if multiple codecs claim to handle the content,
you can optimise for best features, or for decode speed.  If you select
for decode speed if the returned feature set is identical, you can do
some really nifty things like using a more complex codec when some
particular feature of the stream requires it, but automatically using a
faster codec when the feature is not present in the stream.  Also,
developers are less likely to get into an arms race about such things,
especially if there are standard benchmark streams.  If they *do* get
into an arms race, we end up with fast, feature-rich codecs.  I'd call
that a win :-).

		- Peter