https://issues.apache.org/ooo/show_bug.cgi?id=6885
--- Comment #13 from orcmid <[email protected]> 2011-12-02 00:41:12 UTC --- Well, I can tell you what OpenOffice should do if it is intended to make it an ODMA-aware application on Windows 32 (the only place it is supported at the moment). I can't tell you how UCB or any successor needs to be modified to make it work, though. At one time, the OpenOffice.org Novell edition had ODMA support. I ran some tests against it and it was not doing it exactly right (and it only worked with Novell Groupwise, if at all). With regard to previous tests, I believe that OpenOffice.org used the application name "soffice" for itself. There is a problem wiht all of the OpenOffice.org derivatives using the same names for their binaries and to something like ODMA as well as for names of COM servers and DD. In the ODMA case, it means that ODMA cannot be configured differently for side-by-side installs of such derivatives since a single registry key is used to provide the application-name configuration parameters that ODMA relies on. So there are several ways to cut this: A1. I can fix the IP issue around the use of ODMA headers and the derived header which is the real goods. This does nothing to support the ODMA integration though. A2. I can do (1) and explain what the protocol is for detecting ODMA support, determining if there is a DMS assigned for OO.o usage, and then what has to happen to delegate Open, Save, and Save As actions to the DMS via ODMA (and how to respond to the result codes indicating that the user wants to use the file system and not the DMS). A3. Someone figures out how to implement that properly in Apache OpenOffice. I can help see that it is QA-ed and *maybe* review some code. B1. RECOMMENDED. Put all development energies into supporting CMIS integration as well as making WebDAV integration robust. Dump the ODMA stuff completely. Integrate with Notes too (although there was and still might be Notes integration via ODMA [;<). [I haven't checke to see if ODMA support is still in Microsoft Office, but it might well be.) B2. If for some odd reason, the ability to continue integrating with whatever dilapidated DMS servers support ODMA integration, Plan A can be put after B1, providing superior, IP clean (BSD 3-part license) versions of the headers and files that Apache OpenOffice and others can depend on as friendly 3rd-party artifacts. (I can't do an SGA and these can't be moved to ALv2 either.) B3. A few years ago I did a roadmap for taking ODMA into the 64-bit world with component-level integration beyond C Language and limited COM support, in case someone is serious about upgrading DMS client integrations with ODMA in the future: http://orcmid.com/BlunderDome/clueless/2007/11/dmware-how-about-that-odma64.asp. While it is an interesting and fun technical challenge, I find it difficult to believe there is any demand for giving any priority to such a notion. This idea was floated at AIIM and there were literally no responses from any interested parties. Plan B does have the option. With regard to this particular issue, I would mark it "Won't Fix" and move on. If there are ODMA dependencies to remove, treat that as a new issue. -- Configure bugmail: https://issues.apache.org/ooo/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
