Slashdot Mirror

i love linux as much as everyone else but in reality there isn't a product yet out side of exchange that gives the amount of seemless intgration that exchange gives.

So what's wrong with the following products?
http://www.egroupware.org/
http://www.group-office.com/
http://mirror.open-xchange.org/ox/EN/community/
http://www.scalix.com/
http://www.kolab.org/
http://www.opengroupware.org/
http://www.zimbra.com/
http://www.openconnector.org/
Non-free alternatives:
http://www.novell.com/products/groupwise/
http://bynari.net/index.php?id=7
http://www.stalker.com/CommuniGatePro/
http://www.officecalendar.com/
http://www.samsungcontact.com/
http://www.zarafa.com/
http://www.postpath.com/

I look forward to reading your reply.

Has anyone used OpenConnector with Outlook + CalDAV, with success? As it works out, I started looking into ways to make events from my company's application to show up in Outlook *yesterday* - and I was thinking about doing it via CalDAV so I'd be usable on other clients too.

Currently no viable solution exists on a Windows box. There are things like Sunbird and Yagoon but they don't work well with Outlook (i.e. no real integration). Currently there is a project called Open Connector that exists to bring caldav support to Outlook. It is quickly reaching beta but the main developer needs help. I am pitching in and hope that others will as well. Check it out at http://www.openconnector.org./

Also, the calendar server that is used in Leopard is nothing more than the open-source Darwin calendar server at http://trac.calendarserver.org/projects/calendarserver

So, although nothing exists in ports that I can find you can run the Darwin calendar server on FreeBSD.

The question you should be asking is - which shared calendar protocol should we choose?

Good call on the question remark, I'd disagree with your answer.

The problem is that iCalendar isn't calendar 'line' or 'sharing protocol, it's more of a 'serialization/persistance' protocol. iCalendar does not define any connection or query methods. Things like that have to be defined if there is to be any interop. We've actually written tools around the iCalendar/WebDAV combo, they work great for smaller teams, but you run into problems very quickly has the team grows or the calendar's use increases.

As things settle down, CalDAV, a.k.a RFC 4791 will probably become more of an entrenched calendar sharing standard. I've been working on a CalDAV Outlook plugin, Open Connector for quite some time. CalDAV is supported by Apple Calendaring products, Mozill thunderbird, Oracle calendaring server and a bunch of other open-source and commercial packages.

Lightning supports CalDAV for sharing calendar information. Apple announced yesterday that Leopard iCal Server and the iCal application will both talk CalDAV, they released the server at http://trac.macosforge.org/projects/collaboration. Bedework is making a lot of progress as an institutional calendar server.

Oracle has a CalDAV stack. IBM has some stuff in the works as well.

It looks like exchange will have a fight on its hands very soon.

I've been helping on a CalDAV plugin for Outlook called Open Connector, which allows Outlook to take to CalDAV servers like Apple's and Bedework. We always need help, if you have a lot of experience developing COM apps in C++, come help out.

Well the Outlook support is proprietary plugins. Mine relies on an open source plugin
OpenConnector

Its slated for a beta release in May. I am planning to release 1.0 of my project in may as well.

One quick google search using "outlook calendaring open source" yielded this among other items: http://openconnector.org/

Have you USED openconnector before? It's in early Alpha, and requires a whole lot more than Sendmail (as the original poster mentioned, but hey, it's Microsoft bashing, so it's OK not to read the OP right?)

Who needs to resurrect messages from a corrupt data store?

I've been managing Exchange since 5.0. I can count the number of times I've had to rescue anything from a corrupt data store on two fingers (in 12 years). Each time only took a few minutes cause I was intelligent enough to follow standard/best practices.

Who needs to figure out how to keep the mail server running once you've filled the disks with a massive file that you can't move to a larger disk (because it's being accessed)?
Again, if one were to follow standard best practices, this ISN'T an issue. It's also readily apparent you've never used Exchange before, because moving mailboxes is simple. VERY simple. Move to a new storage group, or even a new server with a couple of mouse clicks. Yes it is that easy. Again, hell it's bashing Microsoft, so don't let little things like the truth get in your way m'kay?

Who needs to figure out why people intermittently can't connect to the Exchange server anymore when all the licenses are used?

Licensing is part of the Microsoft world, it's not that difficult. Nor does it take much time. Most companies that use MS products know how licensing work...

Who wants to figure out how to upgrade from SBS to an even more expensive version of Exchange (only to find out that you can't "upgrade")?

You know how easy it is to add new Exchange servers to an SBS Exchange environment? Very. Buy a new copy of Exchange an add to the SBS Exchange org.

Exchange is a fine product for some limited settings. For the rest of us, there are feature-for-feature open source alternatives that will work with Outhouse. They don't entail rediculous licensing problems inherent in Exchange and are engineered better.

If that really was the case, why are not more people moving to them...

Who needs calendaring?

Who needs wireless email?

Who needs signle instance storage?

I guess no one on the entire Mozilla Calendar team or the user community, for that matter, has thought of that right? :)

Not trying to give you a hard time, but what you're asking for would be very, very, difficult. You would essentially have to reverse engineer Microsoft's MAPI over RPC protocol. Many have tried, none have succeeded. Or, if you only support newer versions of Exchange with OWA turned on, use Microsoft's WebDAV based calendar schema built on Exchange WebAccess, like Evolution does.

Mozilla is doing the best they could I think, they're basing their app on a protocol on the IETF standards track http://ietfreport.isoc.org/idref/draft-dusseault-c aldav/ If an organization wants to get rid of Exchange entirely, they then can give their Outlook users a MAPI plugin that supports CalDAV. We're an opensource plugin at OpenConnector.org.

Ximian hasn't figured out the MAPI, they use WebDAV as their line protocol, I suspect. Could be wrong. Exchange supports WebDAV access.

Trying to reverse MAPI line protocol is insane. What you want to do is write a client-side connector, like all the vendors in the article. I'm working on one at openconnector.org

MAPI, btw, is a semi-documented standard. There are at least two books on it. But still, MS keeps tweaking it and doesn't release the changes, so we have to go back and reverse engineer those changes. In all its just a lot of coding, rather and reverse engineering.

But help is always needed. The code is still in alpha, though I'd like to release the first public Beta in November, in time for the projects 3 year aniversary.

Problem is that this is not a simple piece of software; there's a reason it hasn't been done. Very few people understand MAPI, and those who do, understablely want to get paid for doing it.

We need people experienced in MAPI, funds to offset coding time, etc.

I thought so too, and started OpenConnector.Org a while ago to fix this.

An Outlook connector would allow the thousands of Microsoft Outlook users to connect to a CalDAV calendar server or something like Hula

Although we've come a long way with the OpenConnector project ( we now have a MAPI Message Store that loads, and lots of code to base the Transport Provider off of...) a full Outlook connector is still a lot more work. Most completed commercial connectors, I've heard are developed by a team of fulltime developers, so help is *always* needed. Even simple things like the network protocol library, which requires no knowledge of Outlook or MAPI.

At any rate, I think it is a good time for internet calendaring, especially with CalDAV coming out with so much support ( OSA Foundation, Oracle, Mozilla, and many others... ), and on track ( 5 drafts in a few months ).

There needs to be a project initiative similar to what Samba has done for SMB, namely reverse-engineering the protocol used between Outlook and Exchange. That way, full integration without additional drivers would be possible.

Not entirely practical. There is no real protocol between exchange and Outlook traditionally. The whole thing has been done via RPC. Samba did it, but that took an enormous amount of effort. Effort, at least for MAPI, that can be broken very easily.

The best solution I've found, and I am working on, is to write a Outlook connector via Extended MAPI. Our connector is called The Open-Source Outlook Connector Project.

Mozilla plans to use a protocol called CalDAV, which is still in development. We're developing for the same protocol. Hence Outlook and Mozilla would be compatible as far as Calendars go.

"Thunderbird does not offer an equivalent comparison to Microsoft Office Outlook," Microsoft said in a statement. "Customers expect much more than simple calendaring and the ability to send and receive e-mails. The integration of Exchange and Outlook far outweighs any feature that Thunderbird may deliver, and we don't see it as being applicable for serious business use."

Checkout The Open-Source Outlook Connector Project. The project aims to provide a open source connector for Microsoft Office Outlook compatible with other open protocol clients, eg. Mozilla.

So that Microsoft spokesperson will have to come up with something else very soon.