[NTLUG:Discuss] Re: Powerful Combo: OpenExchange (OXch) and OpenGroupware.ORG (OGo)

[Bryan J. Smith]

On Wed, 2004-08-18 at 00:03, Ralph Green, Jr wrote:
> Howdy,
>   At least twice, he make a statement like:
>   'there will _never_ be an "Freedomware" MAPI/XML-RPC connector
> for Outlook.'
>  Why is that?  Is there some fundamental reason it can't be free, like
> a patent protected protocol, or some such?

The Mail API is a core Windows subsystem.  It's hard to build a "clean
room," unlicensed version, although it is certainly possible.  So far,
it's 

XML-RPC might be doable.  But the question is, _how_ will it integrate?

The large part of the problem lies in the fact that "fat" Outlook is so
_tied_ to the Windows _client_.  It's not like CIFS/SMB, which is just a
generic protocol _between_ the client/server.  Outlook is a "fat
instance" on the Windows client itself (not providing a protocol to
other programs).

> I note that his statement is much stronger than just saying that all
> the pieces for an open solution are not available at this moment.

The problem is that you are searching for an "open solution" that
interfaces "proprietary/non-standard" _core_Windows_ subsystem.

We're not talking a _full_ Freedomware Outlook-Exchange replacement --
we have that today with Evolution-OGo.  But a "Freedomware" connector
into a proprietary Windows subsystem.

"At best" we'll have some GPL patches against the MS MAPI toolkit.

E.g., ESP's CUPS.  They have a CUPS-Samba "client" (SMB client driver)
that is built on the Windows DDK.  All they release is a GPL "patch" to
it -- an _older_ version I might add (although it's still probably not
allowed by MS license, let alone GPL requirements).

But you're right, "never" is a strong word.

It better one would be ...

"In the 12+ years of the existance of the Windows MAPI, the Freedomware
community has yet to create a feature-rich MAPI service provider --
especially for any version of Outlook or any of its predecessors (like
Schedule+) -- to _any_ feature-rich server store.  At best we'll have
Freedomware patches to a MS proprietary library/toolkit (e.g., like
CUPS' SMB client driver)."

Maybe if the Calendar Access Protocol (CAP) "takes off," and sufficient
"clean room" (unlicensed) reverse engineering effort goes into
documenting MAPI, we'll have one someday.  But at this point, it's
basically "slim to none."  Because it really is a client-side
requirement.

Vendors like SKYRiX (OGo) try to solve this by making a generic protocol
(WebDAV-based, like many others), and then adding the "connector"
required on the client side to talk to it.  That "connector" uses
software _licensed_ from Microsoft.  It's not going to be easy to
duplicate (let alone a "moving target").


-- 
Time to switch: http://www.mozilla.org/products/firefox/switch.html
-------------------------------------------------------------------
Bryan J. Smith                                   b.j.smith at ieee.org