esby
25th March 2004, 01:21
I am wondering about the actual use of GetVersion()
Since i'm never seen it redefined...
And if it is supposed to allow to check plugin version,
there's something:
- Obviously wrong
- Or that I obviously keep missing...
because if GetVersion() implementation is
{ return AVISYNTH_INTERFACE_VERSION;}
No matter what version we upgrade avs, it will keep telling avs
the filter has been build for this version...
Which I find somewhat useless...
Now if it is supposed to tell for which version the filter was created,
it should be [ return <insertFixedVersionNumberHere> ;}
And the checks in avs (for external filter only i suppose)
should be customized depending the actual support.
let's take a totally fictive example:
supposed we get a version 3.5 and 4.5... ( which will not happend for tomorrow anyway)
supposing 3.5 supports FilterVersionReply 2 3 4
and supposing 4.5 supports 4 & 5
the only implementation that would change would be the one defining the check.
And i'm using 3.5 for 2 3 4, just to put another problem.
If we have a compatibility break, the fact the version number replied is integer, we will not able to detect it properly,
unless FilterVersionReplies are not linked linearly to AvsVersionNumbers (which can be decimal...)
So what i suggests is something like that:
AVS version <----> possible filter version reply
1 <--------------> 1
2 <--------------> 2,3,4
3 <--------------> 5,6,7
etc.
That would allow to easily detect non compatibility,
introduced by adding new member-functions to ICLip...
And since there is no implementation of version 3,
we can use as many filter version number as we'll ever need,
until v3 is out...
esby
Since i'm never seen it redefined...
And if it is supposed to allow to check plugin version,
there's something:
- Obviously wrong
- Or that I obviously keep missing...
because if GetVersion() implementation is
{ return AVISYNTH_INTERFACE_VERSION;}
No matter what version we upgrade avs, it will keep telling avs
the filter has been build for this version...
Which I find somewhat useless...
Now if it is supposed to tell for which version the filter was created,
it should be [ return <insertFixedVersionNumberHere> ;}
And the checks in avs (for external filter only i suppose)
should be customized depending the actual support.
let's take a totally fictive example:
supposed we get a version 3.5 and 4.5... ( which will not happend for tomorrow anyway)
supposing 3.5 supports FilterVersionReply 2 3 4
and supposing 4.5 supports 4 & 5
the only implementation that would change would be the one defining the check.
And i'm using 3.5 for 2 3 4, just to put another problem.
If we have a compatibility break, the fact the version number replied is integer, we will not able to detect it properly,
unless FilterVersionReplies are not linked linearly to AvsVersionNumbers (which can be decimal...)
So what i suggests is something like that:
AVS version <----> possible filter version reply
1 <--------------> 1
2 <--------------> 2,3,4
3 <--------------> 5,6,7
etc.
That would allow to easily detect non compatibility,
introduced by adding new member-functions to ICLip...
And since there is no implementation of version 3,
we can use as many filter version number as we'll ever need,
until v3 is out...
esby