Re: [Evolution] Slow Evolution - OWA - Evolution connector

[Jules Colding <colding omesc com>]

On Wed, 2007-01-24 at 10:06 -0600, Peter Van Lone wrote:
> On 1/24/07, Jules Colding <colding omesc com> wrote:
>
> > OK, I'm obviously biased here but I have a test environment with 4000+
> > messages per folder and evolution-brutus can work with that with no
> > problems whatsoever.
> >
> > Anyway, I'm responsive so if you decide to try out e-b than I'm here to
> > help.
>
> I will definitly try the brutus route ... I want to exhaust what can
> be done with the native exchange connector first, so that I can
> compare "best to best" ...
>
> While I have not yet seriously sat down to figure out how to
> deploy/use brutus, I have looked through the docs a bit, and have
> struggled to come to a "big picture" understanding of how it is
> architected ... I've got a couple questions, do you have a moment to
> address them?

Always :-)


> 1)Brutus must run on a windows box, which can but need not be an
> exchange box. Correct?

Correct. 

One small thing... "Brutus" is the name of the framework. "Brutus
Server" is the name of the part that needs to run on the Windows box.


> 2)What "high level" kinds of config changes must be done on the
> exchange side? Any user accounts required? Any connectors defined,
> etc?

None. The only thing that might possible be requiring Admin rights on
Windows is that the user that the Brutus Server service runs under needs
a few special privileges. This service user can be a special, for the
purpose created, user or it can an existing user.

It is all detailed in the server README.


> 3)Can an EVO installation, use both the "exchange connector" and
> "brutus" at the same time? (or is there an easy way to switch back and
> forth, just for testing simplicity)?

I can't talk for evolution-exchange, but evolution-brutus is able to
tolerate if another process is messing around in its mailbox
simultaneously. 

You will just see two different mail account in the Evolution UI if e-b
and e-e are both enabled. They can be disabled or activated whenever you
want to.


> 4)is there a list of features/compromises that users will experience
> that is compared to the experience using the exchange connector?

The e-b calendar handling is still a little less featureful than e-e,
but that will be taken care of no later than Maj 1. Maj 1 is my deadline
for the last bits and pieces feature-wise. At that point e-b will
handle:

*) The Exchange calendar with 95% of the bells and whistles
*) Contacts
*) Tasks (already implemented)
*) Mail (already implemented)
*) Notes

Later this year we-b will/should be able to traverse firewalls and do
SSL encrypted communication with the server.


HTH,
  jules