Hi
I like that idea. A working prototype can styll be of value. And if we're lucky, after the add-on is mature, maybe /then/ the author will decide that the JCA is not such a bad idea.
I mean, if I have a working add-on, it works well, people love it, and I have the promise that it will go into the OOo tree... I would be much more willing to sign the JCA to see it happen.
That is exactly how DicOOo has come into OOo First it was a standalone macro, lost of my personal website Then it has been reworked (and is still be worked on) and be integrated
It is the normal way for me
On the other hand, i want to point that addons are standalone entities They have their on life cycle and are desiminated all over the web
Why requesting the JCA for pluggin on OOo ?
If i understand correctly, the JCA becomes mandatory when 1- integrated into the main OOo package 2- uploaded on the OOo server
Point 1 is technically ok Point 2 should be avoided
Addon can yes be prototypes but also they are dedicated to handle full features. No need of C++ core rewriting
Thanks to UNO, these foreign extensions can be writtent in C++, java, python, OOoBasic
A lot of languages allowing to attract developpers
Once an addon is widely used and adopted, then rises the question if it is valuable to integrate it.
But if we have a mechanism that allow to install certified packages after install, the integration directly into OOo by default becomes less important
Laurent
-- Laurent Godard <[EMAIL PROTECTED]> - Ing�nierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
