[Fedora-directory-users] Calendar server

[Jeff Clowser]

I know this is somewhat off topic, though it has come up a couple times 
since Red Hat bought the whole suite from Netscape...

http://www.sun.com/smi/Press/sunflash/2005-11/sunflash.20051130.1.html

Looks like Sun is open sourcing JES (which includes the mail and 
calendar server as well as the directory server).  My hope is that 
someone picks this up and adds caldav support to the calendar server, 
spuring the caldav efforts on clients like Mozilla Sunbird, Evolution, etc.

Between FDS (which seems to be improving more steadily than Sun's DS), 
the JES Calendar + caldav, and JES or other ldap aware mail server 
software, I see potential for a real Exchange killer :)

 - Jeff

[Mike Jackson]

Jeff Clowser wrote:
>  I know this is somewhat off topic, though it has come up a couple
> times 
>  since Red Hat bought the whole suite from Netscape...
>  
>  http://www.sun.com/smi/Press/sunflash/2005-11/sunflash.20051130.1.html
>  
>  Looks like Sun is open sourcing JES (which includes the mail and 
>  calendar server as well as the directory server).  My hope is that 
>  someone picks this up and adds caldav support to the calendar server, 
>  spuring the caldav efforts on clients like Mozilla Sunbird, Evolution, etc. 
I searched all over their site trying to find the source code, but no 
cigar. Binary downloads were downloadable for free.


>  Between FDS (which seems to be improving more steadily than Sun's
> DS), 
When it comes to first impressions, the sun ds has fedora beat hands 
down. What I'm talking about is the very slick GUI installer. Of course, 
old pros will still want to use the silent install, which is found in 
sun and fedora ds, but for newbies, I think they will definitely choose 
the sun ds for it's installer. That is, unless we do something about it. 
Competition is _always_ a good thing. Look how many long requested 
features suddenly started popping up in OpenLDAP during the past year :-)

--
mike

[Jeff Clowser]

Mike Jackson wrote:

>  I searched all over their site trying to find the source code, but no
>
>  cigar. Binary downloads were downloadable for free. 
I imagine this was just the announcement, and the release will come 
sometime later.

>  Between FDS (which seems to be improving more steadily than Sun's
> DS), ...
>
>  When it comes to first impressions, the sun ds has fedora beat hands 
>  down. What I'm talking about is the very slick GUI installer. Of 
>  course, old pros will still want to use the silent install, which is 
>  found in sun and fedora ds, but for newbies, I think they will 
>  definitely choose the sun ds for it's installer. That is, unless we do 
>  something about it. Competition is _always_ a good thing. Look how 
>  many long requested features suddenly started popping up in OpenLDAP 
>  during the past year :-) 
I've always used the command line installer for both (I'm generally not 
sitting at or near the server I'm installing it on) so can't speak to 
the gui, and I'm more worried about how it works after the install :)  
The Sun DS replication in 5.2 seems a little more stable and easy to set 
up than 5.1 and below (which is what FDS is based on), but the improved 
Console via apache, as well as increased number of password encryption 
schemes and just the fact that the community is working to improve/bug 
fix FDS is really nice (Sun DS hasn't changed in quite a while).

 - Jeff

[Rich Megginson]

Jeff Clowser wrote:

>  Mike Jackson wrote:
>
> > I searched all over their site trying to find the source code, but no 
> > cigar. Binary downloads were downloadable for free.
>
>
>  I imagine this was just the announcement, and the release will come 
>  sometime later.
>
> > Between FDS (which seems to be improving more steadily than Sun's 
> > DS), ...
> >
> > When it comes to first impressions, the sun ds has fedora beat hands 
> > down. What I'm talking about is the very slick GUI installer. Of 
> > course, old pros will still want to use the silent install, which is 
> > found in sun and fedora ds, but for newbies, I think they will 
> > definitely choose the sun ds for it's installer. That is, unless we 
> > do something about it. Competition is _always_ a good thing. Look how 
> > many long requested features suddenly started popping up in OpenLDAP 
> > during the past year :-)
>
>
>  I've always used the command line installer for both (I'm generally 
>  not sitting at or near the server I'm installing it on) so can't speak 
>  to the gui, and I'm more worried about how it works after the install 
>  :)  The Sun DS replication in 5.2 seems a little more stable and easy 
>  to set up than 5.1 and below (which is what FDS is based on), 
FDS 1.0 replication is based on Sun DS 5.1.  We have also improved the 
speed and stability independently of Sun since then.

>  but the improved Console via apache, as well as increased number of 
>  password encryption schemes and just the fact that the community is 
>  working to improve/bug fix FDS is really nice (Sun DS hasn't changed 
>  in quite a while).
>
>  - Jeff
>
>  -- 
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users

[John Dennis]

On Thu, 2005-12-01 at 13:14 -0500, Jeff Clowser wrote:
>  I know this is somewhat off topic, though it has come up a couple
> times 
>  since Red Hat bought the whole suite from Netscape...
>  
>  http://www.sun.com/smi/Press/sunflash/2005-11/sunflash.20051130.1.html
>  
>  Looks like Sun is open sourcing JES (which includes the mail and 
>  calendar server as well as the directory server).  My hope is that 
>  someone picks this up and adds caldav support to the calendar server, 
>  spuring the caldav efforts on clients like Mozilla Sunbird, Evolution, etc.
>  
>  Between FDS (which seems to be improving more steadily than Sun's DS), 
>  the JES Calendar + caldav, and JES or other ldap aware mail server 
>  software, I see potential for a real Exchange killer :) 
We are also keenly interested in a calendar server but I'll confess I'm
confused as to the relationship you envision between FDS and calendar
server based on caldav, could you explain?
-- 
John Dennis <jdennis(a)redhat.com&gt;

[Jeff Clowser]

John Dennis wrote:

> We are also keenly interested in a calendar server but I'll
> confess I'm
> confused as to the relationship you envision between FDS and calendar
> server based on caldav, could you explain?
>   
>  
Well, I originally said it was somewhat off topic, and I think I'm going 
even further off with this message :)

It's not that I see caldav creating any kind of relationship between FDS 
and Calendar.  It's more along the lines that I want to deploy a FOSS 
messaging solution around FDS, based on open standards - something 
feature wise comparable to Exchange, but using non-proprietary protocols 
so that I can pick and choose clients (and everyone seems to want 
integrated mail and calendar groupware).  That requires at least a 
directory server, email server, and calendar server, implementing SMTP, 
POP, IMAP, LDAP, and something for calendar (caldav).  The one piece 
that is missing in the FOSS world is a true enterprise Calendar server 
(other than web cals...).

The Sun/Netscape calendar server is actually a pretty decent calendar 
server, but it doesn't support any protocols that there are native 
clients for.  There are some that support webdav, and caldav is close 
enough to webdav that there seems to be interest extending that support 
to caldav, which is why the Sun/Netscape cal server with caldav would 
probably be the best option.  (I know Red Hat got the Netscape Calendar 
server along with the Directory server, but the focus is on building a 
community around Directory, while Sun is supposedly opening the calendar 
(and the rest of JES) "very soon now", which is something Red Hat hasn't 
done to this point).

A lot of why calendar is missing from this puzzle is a lack of standards 
for talking to a calendar server (i.e. it's more than just calendar 
events - it's finding free busy times, discovery of resources/other cal 
users, etc).  Caldav is the closest thing to a "standard" for this 
(though I think even caldav is still evolving at this point).  Plus, 
there actually seems to be interest in developing clients to the caldav 
protocol (Mozilla Sunbird, Evolution, etc) - this is about as close as 
I've seen in the calendar world to the equivalent of POP or IMAP in the 
email world.  So, it's important that an enterprise calendar solution 
support caldav or something like it, with native clients that support it 
(the Sun Outlook plugin is not the right direction - it's still using a 
proprietary protocol, limiting you wrt native clients - not to mention 
that it's frustratingly buggy).

That said, it would be nice to see:
- FDS as the directory server (I could go with Sun DS, but FDS seems to 
have a much better community and is improving more/faster than Sun DS).
- Mail server (take your pick - there are a bunch that can integrate 
against LDAP).
- (Some offshoot of?) Sun Calendar server + caldav, hopefully resulting 
in lots of Cal clients, like we have lots of POP/IMAP clients to choose 
from.
- (Jabber/XMPP, if you want to add IM)

My (somewhat tenuous) linking of this to the topic of FDS is that 
hopefully we can break out Calendar, that someone will add caldav, and 
we can talk about integrating that against FDS :)

 - Jeff

[John Dennis]

On Thu, 2005-12-01 at 14:50 -0500, Jeff Clowser wrote:
>  My (somewhat tenuous) linking of this to the topic of FDS is that 
>  hopefully we can break out Calendar, that someone will add caldav, and 
>  we can talk about integrating that against FDS :) 
O.K. got it. Just wanted to make sure one of us hadn't missed
something :-)

We very much want to ship an integrated server product aimed at small
businesses that has many of the components you mentioned and there is an
effort underway internally to make that happen. You are correct that a
calendar server is the single largest missing component.

Having said that, we did look long and hard at what is available and
what is coming along in terms of CalDAV support. You might be surprised
to learn a large proportion of simple (i.e. personal or small group)
calendaring needs can already be supported with existing clients and
servers (e.g. publish/query free/busy, publish/query calendar) typically
only requiring a server capable of HTTP 1.1, not a very hard requirement
to fulfill. CalDAV adds a some niceties, but not so much its impractical
to get along without it. The most complex needs of corporate scheduling
do require a complex calendar server, but CalDAV in and of itself offers
little in this area. There is additional draft for CalDAV scheduling
that is designed to sit on top of CalDAV and provide the more complex
scheduling interactions needed for corporate or large group scheduling.
But this effort is still immature and it does not seem likely to bear
fruit in the near term.

The good news is that a large class of users with simple needs can be
supported with the existing standards (e.g. iTip, iMip) without a
dedicated special purpose server. Is this the best solution? No. Is it
viable in the near term? Probably yes.

We are going to continue to track calendaring efforts and deploy some
solutions in this area. We also may be looking for community involvement
in a small business server project. If you have continuing interest in
this area and/or think you might like to be involved please let me know.
-- 
John Dennis <jdennis(a)redhat.com&gt;

[Kevin M. Myer]

Quoting Jeff Clowser <jclowser(a)unitedmessaging.com&gt;:

>  It's not that I see caldav creating any kind of relationship
> between 
>  FDS and Calendar.  It's more along the lines that I want to deploy a 
>  FOSS messaging solution around FDS, based on open standards - 
>  something feature wise comparable to Exchange, but using 
>  non-proprietary protocols so that I can pick and choose clients (and 
>  everyone seems to want integrated mail and calendar groupware).  That 
>  requires at least a directory server, email server, and calendar 
>  server, implementing SMTP, POP, IMAP, LDAP, and something for 
>  calendar (caldav).  The one piece that is missing in the FOSS world 
>  is a true enterprise Calendar server (other than web cals...). 
I'll put a plug in for a piece of software that might do the trick, 
depending on your needs.  The Horde Project (http://www.horde.org) is 
an overall framework for web applications.  For the most part, the 
modules developed for it are essentially web-based clients for existing 
services (for instance IMP is a mature webmail module).  It has a 
calendar module (Kronolith), which moves beyond simply being a 
web-based calendar client and essentially has elements of being a 
full-fledged calendar server, at least in development versions.  This 
bug tracks WebDav integration: http://bugs.horde.org/ticket/?id=3032 
and there has been thoughts/discussion about CalDAV and GroupDAV.

I agree that a FOSS "groupware" solution is much needed, to break the 
hegemony of the current state of affairs.  A calendar server has 
definitely been the missing link for some time, probably due to a lack 
of standards.  But being able to couple an email server, LDAP server, 
and calendar server together, to provide non-propietary, open-protocol 
access to data from any client (fat, web-based, handheld, whatever) 
opens up a whole new market for FOSS, one that Red Hat has already 
identified, judging from John's post about a small-business product 
(the K-12 education market would probably be pretty happy too).

Have a preference for one mail server over another?  Plug in your 
preference.  Like OpenLDAP over FDS?  Use that instead.  The point 
being that control goes back to the user of the software.  You have a 
bunch of blanks that you can fill with the modules of your choice, both 
server and client side.  Want a monolithic fat client?  Well, as long 
as it supports standards well, you could use that.  Or a pure web-based 
client.  Or mix and match..  With a calendaring server, I see almost a 
generic groupware infastructure emerging, for creating groupware 
solutions, using FOSS, in much the same manner as LAMP/WAMP did as a 
stack for creating web applications.  Maybe its just one of the next 
layers in the LAMP/WAMP stack - MAC (Mail, Addressbook, Calendar) - not 
catchy enough though.

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org