[ DISCLAIMER: Just so everyone notes, I did _not_ start this tangent. My post was that if you choose Exchange 2000, you are stuck with ADS -- that's a technical fact, pure and simple. ] On Wed, 2005-07-27 at 16:13, Les Mikesell wrote: > You use 'chosen' above as to suggest that there are > equivalent alternatives. Are there - for an > organization hat lives and dies by the scheduling > features and shared folders in exchange? This is the type of marketing I'm talking about. Assumptions that Linux can't do something. Major universities and corporations were deploying LDAP and collaboration with 10,000 of thousands of users _years_ before ADS existed. "Scot L. Harris" <webid at cfl.rr.com> wrote: > Like the ones listed here? > http://www.linuxjournal.com/article/8333 > Note: I have not used any of these but they appear to > address most functions currently available via the windows > alternative. The key to understanding Exchange is to break down its _base_ technical features ... 1. X.500 DAP Directory, integrated with LDAP in ADS/2000+ 2. Proprietary MTA, plus IETF ESMTP, POP/IMAP features 3. MAPI and, more recently, XML-RPC store It does _not_ do scheduling. _Client_ side scheduling (_not_ Server** side) is done, using the store -- be it by Outlook or via Outlook Web Access (OWA). Exchange has _never_ been a server-side scheduling system. To get equivalent, you want: 1. An IETF LDAP Directory 2. IETF SMTP, POP/IMAP and other features 3. A server-side store 4. [Optionally] A server-side scheduler #1 and #2 should be obvious, especially if you already have NsDS, Sun One (uses NsDS), etc... deployed in your enterprise. For #3, there are a variety of options. Most use a WebDAV (HTTP) store nowdays, because there are countless WebDAV implementations for various things. More on that in a moment. Bynari InsightConnector (Outlook plug-in) uses a rich, non-email store over IMAP, although the format has changed. Kolab 1 used the same IMAP compatible store as Insight Connector. I believe newer InsightConnector, as well as Kolab 2, are completely different (never personally used these). Calendar Access Protocol (CAP) is slowly becoming de-facto store over WebDAV for calendar information. Many systems maintain their own, proprietary or non-proliferated formats, even if they use WebDAV. For clients that don't support standards protocols, a "connector" is needed. E.g., for Outlook, a MAPI Service Provider. That's how 99% of Exchange Alternatives work, and are _just_as_proprietary_ as Exchange. In fact, most of then _only_ support Outlook/MAPI, and do not work with other clients -- i.e., the store is very much proprietary and Outlook-only. Because these "connectors" use Microsoft code to support Outlook/MAPI, they are _never_ GPL. The problem is Outlook/MAPI, not the server. The key is to ensure the "back-end" server store is open, which WebDAV+CAP is. Even if you use Outlook, you can still have this, although you're going to pay for the "connector." But at least the store will be in an "open format." Beware that even if IMAP store is used instead (e.g., Bynari), it's not a guarantee that the data is "open" (older Bynari/Kolab1 is). #4 is actually _rare_. In most systems, including Exchange itself, the _client_ does the scheduling resolution, _not_ the server. It seems like the server does, but it's actually just a "dumb store" in many cases. There are facilities outside the store -- be it a client, or an add-on product -- that uses the store and makes it seem like the server is doing it. Probably the best "Freedomware" (for #3 with #4) solution is OpenGroupware.ORG (OGo), a release of SKYRiX v4. The server-store is WebDAV (although not CAP yet for Calendaring). It provides various interfaces -- from an intelligent web to its own XML-RPC to Palm.NET (yes, synchronize Palm _directly_, without a "host") to Evolution to Outlook. In the case of Evolution, a "connector" is used (but is free). Same deal for Outlook (but it is not free). Since the server/calendaring store is in a "unified open" format (unlike most Exchange Alternatives), OGo can and does do _true_ server-side scheduling. This includes direct web, Palm, XML-RPC, Evolution and Outlook scheduling at the _server_, which the client then synchronizes with. Systems that don't do #4 rely on the clients to handle updates to the store, which can create a _mess_ if one screws up. -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers)