-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03.01.2015 12:48, Alexandre Bique wrote:
>> 3] It would make plugin development easier if it was required to
>> call deactivate() on a plugin before clap_destroy'ing it. The
>> additional burden on the host would be small. Is there a good
>> reason for it to be this way?
>
> I did it this way for robustness reasons. Because even if the host
> has a bug in his destroy code path and forgets to deactivate, the
> plugin must handle this case correctly.
OK, let me put it this way. It really is a number's game. Let's take a
successfull plugin standard like VST. There's thousands, maybe tens of
thousands of plugins, but maybe tens to hundreds of hosts. So there's
an order of magnitude or two difference.
Every plugin has to have this extra check. What are the chances that a
few plugin authors forget to do this check? What are the chances that
a few hosts get this wrong? What are the chances that plugins get
fixed? What are the chances that hosts get fixed? Also it's just
boilerplate code. If every plugin has to do it, then it shouldn't have
to do it at all since it clearly can be automated. And the automation
in this case is just the host calling deactivate before destroy.
Give the plugin authors as much guarantees as possible.
With the proposed way around plugins might work in some hosts that
honour the standard, but not in others (I.e. ones that do call
deactivate() before destroy() vs. those that do not). If you make
calling deactivate() before destroy() a requirement this whole problem
just goes away. It makes life easier for the plugin developer while
not making life _much_ harder for the host dev. Also it's trivial to
implement a test plugin for host devs to use that checks things like
this - one that does basically just copy input to output but checks
that lifecycle requirements are met by the host:
- - abort() on calling process() before activate
- - abort() on calling destroy before deactivate()
- - etc..
Have fun,
Flo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJUp/nYAAoJEA5f4Coltk8Zk+AH/0mnqvtw09iw2Mccyj4UTzBY
xgm7n0i9N664e2qk2a0JrmRs/gOxAy1ddMGiNbXzgfI+mMqdh1XRlIgm0APcu+mK
xAyxsYQuNVM88wq1kVVETAve/dvdAqMVYFkwViR5a7HlPPZVzj0vAsbAJT8HNWE3
O9oayGVDkzvY30ax13ktrFGSiMgiY1qEZq9DhapxTSwr929LnIGHzCWNSEXTepxi
iSF/5k4j61V/zEFCNjL1/gHOdvANwKTbSQTXcNUY8RrbiR6vU18H/7wEypIbNI9a
4s4lHdzw4paAcIuj/Xvjqc8NUGi67z6BGRKqDU9y6jPg99T7vqX4lFCIScFV2go=
=0gbu
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Jan 3 20:15:02 2015
This archive was generated by hypermail 2.1.8 : Sat Jan 03 2015 - 20:15:02 EET