Thank you for translating your reply and thus enabling me to answer ;-)
I strongly agree that client support is the crucial messure of success, but please don't confuse the backend server product with that. Postfix, OpenGroupware, exchange4linux and Kolab are all server products. Most, if not all, of these offer clients access to their full range of features using platform neutral protocols such as IMAP or POP3.
Not so with Exchange... The *only* way to achive Exchange integration on an equal footing with MS Outlook (feature- and performance-wise) has previously been to use MAPI. Brutus is now enabling any client to access Exchange on that same level, being it on Windows or not.
But to return to your point, client support. Nobody would care the slightest about Brutus unless clients are supporting it. I fully expect that I need to do that part myself. Our first project would probably be to create an Evolution Brutus plugin. Any help would be greatly appreciated :-)
I would appreciate alternatives, but clients must be GPL'ed or they must have a commercial Brutus license. I really don't see any other realistic choices than Evolution, considering the available GPL'ed groupware products, but I am always open for suggestions.
Another interesting option is to use Brutus to build a
MAPI <=> Brutus <=> <ANY PROTOCOL>
gateway. That gateway could give, say IMAP clients, way better access to Exchange without them having to support Brutus natively.
My French is non-existant but babelfish managed to get some meaning out of your comments. It seems to me that there is a little confusion about the technical basis of Brutus, so I'll try to clarify that in a few words. I'll hope you'll forgive me for keeping this post entirely in English.
Brutus is technically speaking a CORBA wrapper that wraps native MAPI in a large set of appropiately defined CORBA methods and types. It is therefore a requirement that the Brutus server part is installed on some Windows server where the correct version of the MAPI dll is located. The Exchange server itself is the supported choice.
The Brutus IDL files, on the other hand, makes it possible for *any* client to connect to Brutus, and thereby Exchange, as long as some CORBA implementation is available on the client box.
The primary goal of Brutus is to enable any client to integrate into an Exchange infrastructure on an equal footing with Outlook.
[^] # Re: In short..
Posté par colding . En réponse à la dépêche Enfin un connecteur Linux pour Microsoft Exchange 5.5. Évalué à 2.
[^] # Re: In short..
Posté par colding . En réponse à la dépêche Enfin un connecteur Linux pour Microsoft Exchange 5.5. Évalué à 5.
Thank you for translating your reply and thus enabling me to answer ;-)
I strongly agree that client support is the crucial messure of success, but please don't confuse the backend server product with that. Postfix, OpenGroupware, exchange4linux and Kolab are all server products. Most, if not all, of these offer clients access to their full range of features using platform neutral protocols such as IMAP or POP3.
Not so with Exchange... The *only* way to achive Exchange integration on an equal footing with MS Outlook (feature- and performance-wise) has previously been to use MAPI. Brutus is now enabling any client to access Exchange on that same level, being it on Windows or not.
But to return to your point, client support. Nobody would care the slightest about Brutus unless clients are supporting it. I fully expect that I need to do that part myself. Our first project would probably be to create an Evolution Brutus plugin. Any help would be greatly appreciated :-)
I would appreciate alternatives, but clients must be GPL'ed or they must have a commercial Brutus license. I really don't see any other realistic choices than Evolution, considering the available GPL'ed groupware products, but I am always open for suggestions.
Another interesting option is to use Brutus to build a
MAPI <=> Brutus <=> <ANY PROTOCOL>
gateway. That gateway could give, say IMAP clients, way better access to Exchange without them having to support Brutus natively.
Best regards,
jules
# In short..
Posté par colding . En réponse à la dépêche Enfin un connecteur Linux pour Microsoft Exchange 5.5. Évalué à 10.
My French is non-existant but babelfish managed to get some meaning out of your comments. It seems to me that there is a little confusion about the technical basis of Brutus, so I'll try to clarify that in a few words. I'll hope you'll forgive me for keeping this post entirely in English.
Brutus is technically speaking a CORBA wrapper that wraps native MAPI in a large set of appropiately defined CORBA methods and types. It is therefore a requirement that the Brutus server part is installed on some Windows server where the correct version of the MAPI dll is located. The Exchange server itself is the supported choice.
The Brutus IDL files, on the other hand, makes it possible for *any* client to connect to Brutus, and thereby Exchange, as long as some CORBA implementation is available on the client box.
The primary goal of Brutus is to enable any client to integrate into an Exchange infrastructure on an equal footing with Outlook.
Best regards,
jules (www.omesc.com)