Probably most of you have heard or read about Novell's effort to provide VBA support in OpenOffice.org for better interoperability with a well known competitive office suite. On the other hand Sun has a similar VBA migration story in place for StarOffice. Sun's solution is designed as an extension which is 100% optional whereas Novell's solution prefers the integration directly in the code base. So we have two similar solutions which overlap in many areas. This is a sub-optimal situation and probably nobody would disagree here. The good news is that both companies have come to an agreement that it makes sense to share their resources and work together on one common OpenOffice.org VBA story.
 
The question is how it will work and how should it look like?

The answer is quite simple. We take all the code that we have, we mix it and mix it and mix it and put everything into OpenOffice.org and hope that it will work!
No of course not, we won't do that. We have evaluated what would be the best way to go forward and bring both solutions together. The first difference is that Novell uses C++ and Sun uses Java as implementation language. We decided to go forward with C++ in the future because OpenOffice.org itself is implemented in C++ and that allows us to use some internal C++ API's directly where currently no UNO API is available.

Sun will continue the still ongoing work to make the StarBasic interpreter and engine in OpenOffice.org more VBA compatible and faster. That is a natural decision because Andreas Bregas the main developer of the StarBasic engine is a Sun employee and a great expert in this area. But not to forget that Noel Power from Novell has contributed a lot of patches here as well. Andreas will also define a new interface to register new global symbols in StarBasic and he will probably work close together with Noel. This new API is important to be flexible for the future. One design idea from me is to be able to install collections of new symbols as separate extensions. But of course that is not so important at the moment .

Sun will also help in all application areas where API's are missing or some special modifications will be necessary. Also this is natural because most of the core developers are Sun employees as well.

The last and most important part is that Sun will open source it's Java-based implementation as a more or less implementation template to speed up the implementation of VBA symbols. The hope is that we find volunteers in the community who are interested to help in this project. We search for help to convert the Java code to C++ and to combine it with Novell's code because only that makes sense to create a common solution. Currently both implementations have their own helper models and helper classes/functions and it makes no sense to have this code twice. A further benefit is that Sun's solution addresses Word VBA symbols as well whereas Novell's solution focused on Excel only at the moment.

Novell is restructuring their current implementation and will put their VBA specific implementation code in a separate library to provide a more modular architecture. This allows to deploy the whole VBA stuff later optionally. People who want to work with ODF only won't have to install it and can work with the OpenOffice.org API as usual. It would be the decision of the user or maybe of the vendor who provides a specific OpenOffice.org distribution!

Novell will probably also help to convert the Java implementation to C++ to make use of already implemented symbols in the Java library. Anyway i am looking forward to this project and hope that a lot of VBA junkies will join the project to bring in their knowledge and their manpower.

I think that are really good news and it is the best decision for the project to address this important interoperability feature. You are all welcome to join this project and help to bring it forward.

For all paranoid users who see the potential security issues coming for OpenOffice.org. Keep cool! The whole stuff can be disabled and we will take care that at least our normal security mechanism for StarBasic will be used as well.

Some more infos:

Sun's Java based implementation is available in the source module api/helperapi. The UNO IDL definitions have to be reworked, especially the service definitions because they are currently in old style notation because of backward compatibility to StarOffice 7. This module will never built during the normal OpenOffice.org build, it is only for the migration into a common source base. We will combine it with Novell's symbol set and during this step the type definitions should be adapted. The new combined API becomes available under api/oovbaapi and becomes it's own namespace/module. Noel Power is already working on this new module in the cws npower6 where he is working also on changes to bring the VBA code upstream into the main trunk of the OpenOffice.org code base. Thanks Noel!

tags: openoffice.org staroffice starsuite vba