On Wed, 2007-01-24 at 10:06 -0600, Peter Van Lone wrote: > On 1/24/07, Jules Colding <[EMAIL PROTECTED]> 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 _______________________________________________ Evolution-list mailing list Evolution-list@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-list