It's been suggesting to combine crypto plugins into one plugin. I'm researching and a few questions arose:
1) are plugins supposed to be thread-safe? Some plugins have state modified by its primitives (DESPlugin, DSAPlugin)
2) some are subclassing InterpretedPlugin and some are subclassing SmartSyntaxInterpreterPlugin. Which should the combined CryptoPlugin subclass, preferably? Either way, there is rewriting needed.
3) should we have 2 plugins (SmartCryptoPlugin and CryptoPlugin) initially, then rewrite?
I appreciate, Robert
On Sat, Dec 12, 2015 at 04:53:27PM -0500, Robert Withers wrote:
It's been suggesting to combine crypto plugins into one plugin. I'm researching and a few questions arose:
- are plugins supposed to be thread-safe? Some plugins have state
modified by its primitives (DESPlugin, DSAPlugin)
It is best if plugins to not maintain state, but it is not strictly required. If they do maintain state, then it is the responsibility of the image to be aware of it and put appropriate protections in place.
- some are subclassing InterpretedPlugin and some are subclassing
SmartSyntaxInterpreterPlugin. Which should the combined CryptoPlugin subclass, preferably? Either way, there is rewriting needed.
You will need to look at the code and see which is the least amount of work. But IMO you should take a close look at whether this suggestion is a good idea in the first place. What problem are you trying to solve? If you undertake the work, what value will you receive from doing it? Are you prepared to keep image side code properly synchronized with the plugins in various VMs?
- should we have 2 plugins (SmartCryptoPlugin and CryptoPlugin)
initially, then rewrite?
No. Do it once or not at all, otherwise you have unnecessary confusion in maintaining code in the image that is dependent on those plugins.
Dave
cryptography@lists.squeakfoundation.org