26 Apr
2006
26 Apr
'06
6:48 a.m.
don't think that the string is needed
I think that's fair.
One version number should be enough though,
and it doesn't have to match the actual version of the LADSPA spec
Both those points (especially the second) sound simple and sensible.
Okay, so on reflection...
There's a case to be made that some version information ought to go
into the struct, since it directly affects how the struct may be
properly accessed.
There are two case where you would need version information
to correctly access the struct.
1) A future version extends the struct. (does not break backwards compatibility)
version information is needed so that eg. a 2.1 host does not try to
use 2.1 functionality in a 2.0 plugin.
2) A future version modifies the struct. (breaking backwards compatibility)
case 2) is very unlikely to occur anytime soon, so let's just forget about that
(it can be solved by using a new discovery function anyhow)
case 1) could most simply be addressed like this:
The struct starts with a single unsigned short.
The host must check the version number at the start...
If the plugin version >= host version:
No problem - the host knows it's functionality is fully supported.
If the plugin version < host version:
The host may access the plugin normally and is aware of what
functionality the plugin does not support.
Why is this useful?
Well, it provides a _built-in_ way of ensuring that the struct is
properly accessed,
even if the metadata file is corrupted or lost.
Say a user meddles with the metadata file to make a 2.0 plugin look
like a 2.1 plugin. The host attempts to access 2.1 functionality and
core dumps.
Say the metadata file has been lost - the plugin contains sufficient
information to remain accessible although it no longer has any
associated metadata.
I realise that the LADSPA library should mostly enforce keeping things
okay, but it seems like a nice idea to have a protected way of making
sure that we don't accidentally attempt to access invalid memory when
things go wrong.
I would suggest then: A single unsigned short at the start of the
struct, starting at '0' for ladspa 2.0 plugins and incrementing if and
when the struct is extended.
The LADSPA major and minor versions would stay in the metadata.
Any milege in this?...