incubator-ooo-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 6885] Lack of ODMA documentation
Date Fri, 02 Dec 2011 00:41:12 GMT
https://issues.apache.org/ooo/show_bug.cgi?id=6885

--- Comment #13 from orcmid <orcmid@apache.org> 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.

Mime
View raw message