Re: [Evolution] Can Evolution connect to an Exchange server shared mailbox?

[Jules Colding <colding omesc com>]

On Wed, 2007-03-07 at 21:33 -0500, Paul Smith wrote:
> On Wed, 2007-03-07 at 14:31 -0700, Robin Laing wrote:
> > Jules Colding wrote:
>
> > > <yet another shameless nudge in the other direction>
> > > Why don't you try Brutus? I've successfully run e-b while using several
> > > Exchange mailboxes simultaneously. 
> > > </yet another shameless nudge in the other direction>
> > I see that most of the people that are having issues with Evolution and 
> > Exchange (like myself) don't use Windows or are getting away from their 
> > Windows systems.  Where can I get this Brutus for Linux?
>
> Er... you can't.  That's the whole point.  If you could, then why
> wouldn't Evolution use that method instead of the much more dodgy OWA
> interface?
>
> The Brutus solution uses the same Windows DLLs as Outlook to access the
> Exchange server; these libraries use a proprietary Windows protocol that
> is not published by Microsoft, so no one knows what it is or how it
> works.
>
> So, no implementation of it can be created on Linux [1].

A small correction is needed here I think...

It correct that you can't have Brutus Server (the executable) for Linux,
but the point of Brutus is that you don't need it!

Brutus is a CORBA system which means that the Brutus server process,
which is running on Windows, is exposing the entire MAPI interface to
clients in a platform independent manner. This is done by implementing a
fairly large number of CORBA objects in the server process. These
objects are then wrapping the native MAPI object.

With CORBA it doesn't matter where the actual physical server process
is. Any and all clients will be able to use these objects, that are
implemented in the server, as if they were objects local to the client
process.

Therefore - Brutus makes the need for a native Linux MAPI implementation
effectively moot(*). 

Best regards,
  jules


(*) It could be argued that a native Linux implementation using the
native MAPI wire protocol is "cleaner". I would on the other hand argue
that it doesn't matter much. The MAPI API has been set in stone for many
years while the wire protocol might have changed from time to time. So
using the MAPI API as opposed to reverse engineering the wire protocol
is, IMHO, the robust design decision.

> -----
> [1] Unless someone reverse-engineered the protocol.  But this is a HUGE
> undertaking and no one is interested enough in interoperating with
> Exchange to do it for free.  Maybe someday someone will care enough to
> pay $$ to have it done.
>
> _______________________________________________
> Evolution-list mailing list
> Evolution-list gnome org
> http://mail.gnome.org/mailman/listinfo/evolution-list