There are some problems with plugins at the moment... Cyberdo has written a plugin API which is partially designed for security, and therefore wraps many classes, and doesn't give access to e.g. Node. In future, extensions to this may allow for untrusted or semi-trusted plugins; a custom Loader might only allow access to plugin-safe classes for loaded jar files.
Bombe has written a really simple plugin API which allows you to access everything, without wrappers. Neither of these is documented. We need a single, documented plugin API. What is the next step? I can certainly see an argument for plugins only to be able to access plugin-safe or specific classes, although actual untrusted plugins support is probably some way off... And it is clear that there should be a set of interfaces and/or classes which are available to plugin devs, and are clearly documented, rather than them having to understand all the complexities of the node... So generally I side with cyberdo's approach... -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060613/b74be227/attachment.pgp>
