Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
UPDATE: The timeline has been extended by 12 months and some additional migration considerations introduced.
As we migrate over to 64-bit desktop PCs, I don't expect early demand for a 64-bit version of ODMA, the Open Document Management API and its supporting middleware. Still, it seems useful to envision what a practical migration to an ODMA64 could be. I'm thinking that 2008 can be spent stabilizing ODMA 2.0 fixtures, with ODMA 64 defined during 2009. Implementation and availability would be in 2010. That way, we won't be caught too short by whatever demand, if any, that does arise, as part of the movement of desktop clients to full 64-bit operation.
A Timeline
November 2007: I've begun to capture ideas for ODMA64 in ODMdev note pages. Those notes will be revised and expanded as I capture my own thoughts and those of stakeholders wanting to see and invest in an ODMA64.
UPDATE 2008-02-15: I have slipped the remaining time line by 12 months, adding in time for the stabilization of existing material and work toward an ODMA 2.5 supplement.
March 2008: The Open Source materials on ODMA will become available on the SourceForge ActiveODMA Project. There will also be a CD-ROM of the official core materials, SDK, and specifications. This repository will be expanded with the ODMA 2.5 supplemental materials and fixtures over the next 12 months.
Spring 2009: I'm promoting an ODMA reunion/get-together in conjunction with AIIM 2009 in the Spring. What I want to appraise is
Whether there is enough life and value in ODMA to migrate to 64-bit at all,
Whether the idea of preserving but enriching the "sweet spot" ODMA functionality is agreeable
Whether there is some superior avenue that should be encouraged instead of ODMA
Spring 2010: Assuming that there is headway toward ODMA64, use the occasion of the next AIIM Conference to get together and confirm any work that has been done and agree on how to distribute and integrate with ODMA64, conduct interoperability tests/demonstrations, and assure ODMA64 stability and dependability.
Suggested Constraints
No Second-System Syndrome. No major feature or function madness. Do enough to have it work great, but no more.
Preserve the Sweet Spot. Continue to support the integration that has worked so well in the ODMA32 world, holding onto the feature set and use cases that matter for most applications that rely on ODMA integration.
Take Out What's Never Mattered. Simplify wherever possible to keep the functionality simple and conceptually coherent. Be a reliable connector and let the desktop software and the DMS integrations provide appropriate richness and feature competition.
Progressive Migration. Operate by incremental/iterative improvement of what there is to provide a stable ODMA32 framework for proof-of-concept and bridging to ODMA64.
Define the ODMA model that ODMA64 supports as ODMA 3.0. Make important core improvements along with removal of those features in ODMA 2.0 (such as code-page based 8-bit character strings) that have no survival value and that do not need to be a drag on new ODMA64 integrations.
Introduce a hybrid layer, defined as ODMA 2.5, operating on Win32. ODMA 2.5 provides Win32 versions of the ODMA64 core improvements via supplemental wrappers above and below ODMA32 on Win32. Existing ODMA32 components would continue to operate properly.
Develop the hybrid layer using bridges already envisioned for ODMA32 integration with Java, .NET, direct COM, and possibly ActiveX/IDispatch.
Added 2008-02-15: Explore means for implementation of managed-code DMS integrations (Java, Mono, or .NET) below the native ODMA32 (and ODMA64) Connection Manager implementations.
Added 2008-02-15: Explore means for discovering short-circuiting of the native-layer Connection Manager when a client-compatible managed DMS interface is available. Bypass native-platform interop and data-conversion layers whenever possible.
Core Improvements
The following improvements seen essential:
Complete end-to-end Unicode UTF16 support
Reliable and consistent integration of DMS modal dialogs with the desktop application program's GUI
Thread safety and proper multi-threaded behavior
Complete logging and operational confirmation/troubleshooting capability, with proper behavior when multiple ODMA applications are operated concurrently
Easy power-user/administrator configuration control and inspection, with customization by user account, not just by machine
The ODMA64 Connection Manager and supporting utilities would be provided under the current modified-BSD template license.
If this were to be done, my objective would be to ensure that the ODMA integration layer is the most dependable and stable portion of the desktop-program through ODMA to DMS-integration stack.
When I celebrated the 10th anniversary of ODMA in 2005, I was already bemused that I had somehow become its exclusive source of general support. Despite my own appraisals of ODMA as a niche with dwindling share of attention and interest, I am actively developing new fixtures for use in making ODMA-aware application software and DMS integrations. For now, I get a lot out of it, especially practice toward developing other software. Now we'll see whether there is sufficient community interest for development of ODMA64 to be worthwhile. I should probably update that analysis of where ODMA is going.
[update 2008-02-15: While adding 12 more months to the timeline for progressing toward ODMA64, I also added two additional challenges to be explored concerning interop with managed-code DMS integrations. update 2007-11-11: While correcting a duplicate wording I added a few clarifying bits. Well, it clarifies for me what I wanted said, if it's not clear for you, ask.]
