Oh dear, my past comes along to haunt me. If you go to the home page, http://odma.info, you'll see that the other Downloads link is to ODMA License 1.0 (modeled on the BSD License). If you look in the lower right hand corner of the license page, you'll know why I should be hiding behind the sofa.
We pulled this together in 2004 because someone was concerned about using those headers and redistributing the ODMA 2.0 Connection Manager. I think it was Michael Meeks, but we didn't know what he needed it for. I notice that there are still dialogs in LibreOffice to control whether ODMA dialogs are used or not. I did some tests at one point and discovered that the code was brittle and didn't adapt to the absence of ODMA support the way it is supposed to. That was 3-4 years ago and I haven't tested a *Office.org drop since. I think I also fumbled an e-mail exchange with the developer. (Tor Lillqvist, last communication in March 2008.) The only complaint you might get is from folks who rely on the integration of *Office.org with Groupwise, wherever it might still be running. I think the current ODMA code in *Office.org is basically enough to work in a Groupwise configuration and chancy otherwise. But don't take my word for it, I don't follow these products any longer. If I had to prioritize, I would recommend CMIS integration first, keep rounding the edges on WebDAV support, and I don't know what to say about Groupwise via ODMA. - Dennis BACK STORY, EXCESSIVE DETAILS The site is still mine though. I've never modified the headers to mention the license, although I have a partly-refactored set of headers that work better, if I dare to say it. Incomplete work. The ODMA SDK is not what you really need. You need to dynamically load the ODMA Connection Manager, if it is present, and bind only the entry points you need, especially because you may have a down-level Connection Manager or it may be connecting you to a down-level DMS integration. Also, you need to be prepared to fail to find that there is a DMS configured for working with swriter (the usual app) even though the ODMA Connection manager is present on the system. It is all about negotiation and dynamic binding and the SDK doesn't address that at all. (Think of ODMA as TWAIN for document management back in early client-server days.) There are even exposed COM interfaces that might fit with UNO, although the C Language bindings and the COM interfaces have some odd semantic differences. (I built a COM binary-interface static-library wrapper for ODMA that needs to be refactored, but it worked well enough to provide Java access to ODMA via JNI.) You can use the header file(s), or an improved derivative of the headers (and I might be coaxed), but the SDK doesn't tell the real story for a production integration. The .lib is not what you want to statically bind into your program, and the only other material consists of two mildly defective samples good for a little smoke testing but not much else. - Dennis -----Original Message----- From: Kai Sommerfeld [mailto:[email protected]] Sent: Tuesday, June 21, 2011 00:57 To: [email protected] Subject: Re: Some more strange files in the OOo code Hi, On 21.06.11 09:25, Mathias Bauer wrote: > Hi, > > some more strange files I found in the OOo code: > [...] > (6) Header files only with Copyright header, but no license > [...] > ucb/source/ucp/odma/odma.h > The ODMA stuff is not even build. Seems, that the copyrighted header file was accidentally checked in by me back in 2007 (shame!): 2007-06-05 INTEGRATION: CWS bgdlremove (1.4.240); FILE MERGED 2003-08-25 INTEGRATION: CWS abi4 (1.3.2); FILE ADDED 2002-02-22 don't check in the real file here - only point the people to the place to download file 2002-01-14 first revision for odma impl For now, we can remove the file (and even the whole ODMA stuff?). If we want to have ODMA support in OOo in the future, we should pull in the ODMA SDK (http://odma.info/downloads/#ODMA-20-SDK) like we do with every other external stuff we use. - Kai.
