On Thu, Nov 04, 2010 at 02:43:07PM +0100, Frank Gevaerts wrote:
> Are there fundamental reasons not to commit FS#8806?
OK, my impression is that while most people would prefer the codec
version on principle, the limitations imposed by a codec (available
memory) are important enough to tip the balance to the plugin side.
That would mean we have two remaining questions:
1) What do we do with the existing codec?
I see three options:
a)Remove it altogether, leaving only the plugin to play mod files.
I don't like this one. The existing codec works fine for some
classes of mod files, removing it would be a serious regression for
people who only/mainly have those files.
b)Leave it unchanged.
This way some (classes of) files can still be played using the
normal playback mechanism
c)Commit both the mikmod plugin and codec.
This way all filetypes would be playable using the normal playback
mechanism, with only the specific files that actually are too large
needing the plugin. I haven't checked this, but my guess is that
the new codec will have a lower limit than the old codec (it
supports more, so presumably it has more code), so possibly some
files that play fine using the existing codec would need the
2) (assuming 1.b or 1.c is chosen) Does the plugin or the codec have
priority when picking a file?
This should only make an actual difference when selecting a specific
file. Adding a file to an existing playlist or adding a directory to
a playlist would always work as expected.
(I have really no idea what this means technically, i.e. how to
implement either choice. I assume viewers.config is involved, but I
don't know what else)
(Also note that I don't usually play any mod files myself, so I really
can't form proper opinions on these questions. I can only try to
detect a consensus)
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Received on 2010-11-07