[ 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@xxxxxxxxxx> 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@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
