Dany, this is a well thought out and presented topic that fits well within the scope of this forum. Unfortunately your topic falls into the "rather complex" category, so the answers may not be what you want. Also, OOo does support OLE within a Microsoft environment as can be seen from my attached DOC example, which is a simple document that embeds to OLE objects: a Word document and an OOo one. You can open this in both Word and in OOo, and if you use the latter to save it as an ODT file then this can be used to get a better insight as to how OLE encapsulation works in files. If you open the ODT file with WinZip or any equivalent ZIP utility (the easiest way to do this is by temporarily renaming the file to a .ZIP extension), then you will see that in ODF (unlike MS CBFF) the two OLE objects are just embedded files within the container, and the content.xml refers to them both in the same way.
At its simplest OLE encapsulation at a file level is simply a mechanism for embedding a byte-stream which itself forms a document of some type. Most of the OLE smarts relates to the use of standard APIs so that one OLE application can embed other types of OLE documents and that the user can seamlessly switch from one application context to the other with both applications sharing the GUI. An OLE descriptor is associated with each encapsulated OLE document. In the case of Word documents this is Word.Document which itself points to the default version (Word.Document.8 in the case of MSO 2003); and in the case of an 00o text document soffice.StarWriterDocument).
Now OOo will happily open a Word document, and if you take the above ZIP file and open Object 2 with OOo you will see that it opens the Word Document stream happily. All of the mappings for the OLE objects Word.Document* embedded in the registry. I suspect that you might be able to clone the registry declarations for Word.Document* pointing these that OOo for registration on machines which don't have MSO installed. This sort of trial set up needs to be done on a sandpit PC. I have MSO installed on my XP machines as well as OOo, so I don’t want to try out as I don't want to mess up my installation. However this is a botch at best, and therefore should only be attempted as a matter of last course.
There is even a Tools->Options setting whereby it convert any embedded MSO OLE objects and open then in OOo but only if you don’t already have the MSO OLE providers registered (which is again something that I can’t try out easily, because I have MSO installed).
The challenge that you have is that your current OLE embedding architecture is highly MS specific and uses complex MS APIs and stacks that they really
don’t ant to make it easy to unroll. (See MS Compound Binary File Format
Batch conversion using COM to relevant MSO COM Application doing a SaveAs to a filestream is easy, and migrating to a database which uses RAW stream BLOBs for encoding DOCs etc. would probably be the easiest migration path, and involve the least code integration. Any move away from OLE encapsulation to RAW stream BLOB storage would also require “wrapping” for the legacy MSO integration.
Ideally what you want to use some JiT extract utility which can extract the raw DOC streams from the There are a number of Open Source utilities to do this such as Jakarta
. From what you say, you seemed to imply that you have the source code for this application. They should make life a lot simpler.
Picking up some of your specific points: for reasons discussed about you only want to consider two runtime scenarios:
- The client has MSO installed and uses MSO as the document editing vehicle.
- The client has OOo installed and uses OOo as the document editing vehicle. MSO is not installed.
Do not try to get an OOo option installed where MSO is installed or is no longer installed and the registry is not properly cleaned out.
Not sure about your “update” issue. This works fine for me in embedded mode.
The other place to try posting is in the developers mailing list. What I believe I am saying is that you are probably going to end up going down your “black scenario” of a total re-write of the document handling functionality. Sorry that I can’t be of more help.
Ubuntu 11.04-x64 + LibreOffice 3 and MS free except the boss's Notebook which runs XP + OOo 3.3.