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
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
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@redhat.com>
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
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@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users
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
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@redhat.com>
Quoting Jeff Clowser <jclowser@unitedmessaging.com>:> 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