Tuesday Apr 26, 2011

Calendar Server for CALDAV Clients 7 Update 1: New Patch Available

Oracle Communications Calendar Server for CALDAV Clients 7 Update 1 has shipped a new patch (patch 3). The patch IDs by platform are:
  • Solaris: 142785-03
  • Solaris x86: 142786-03
  • Red Hat Linux: 142787-03

To obtain patches:

  1. Log in to support.oracle.com.
  2. Select the Patches and Updates tab.
  3. Type the patch id in the search box and Search for the patch.
    Selecting the patch will take you to the patch information page.
  4. Click the Download button.

Wednesday Sep 23, 2009

Calendar Server 7: A Look at Sun's Upcoming CalDAV Release

Hat Tip DougG

It might not be widely known at this point, but Sun has been a leader in the CalDAV community, and our investments are about to pay off with the upcoming shipment of Calendar Server 7, included in the Communications Suite 7 release.

Sun is firmly committed to making CalDAV our calendaring protocol of choice. Sun has been very active in the CalConnect community to make sure that our CalDAV service interacts with other vendors and their services. Project Aries has been the name of Sun's CalDAV effort, and for the past year, we've enabled customers to get a taste of our technology through a hosted preview.

Why the need anyways for a CalDAV server?

The challenge in the calendaring space has always been about getting everyone to agree on a standard protocol that enables data to be exchanged between a calendar client and a calendar server, regardless of vendor. To date, we've been using the iCalendar data format for calendar and task data, as specified in RFC 2445. The good news has been that Sun and others have used this common data format. The bad news with this approach has been that, lacking a standard protocol, you end up using one big file to store all your calendar events. Reading calendar info may be fine, but making changes is not. Because your calendar database is essentially one big flat file, the only way a change can be made is for the client to upload a new version of a user's entire calendar data file and overwrite the copy on the server. That's a lot of data to move, for example, when all you have to do is push out a meeting change of one hour. The situation worsens if multiple users want to update a calendar. The last user to overwrite the copy on the server wins and changes other people have made are lost.

Having a real calendar access protocol would solve these problems and provide other nice features, such as calendar sharing, change logs, and free/busy lookups. The first attempt at such a protocol came in 1999 with the creation of the Calendar Access Protocol (CAP). WCAP, or Web Calendar Access Protocol, is an implementation of CAP over HTTP. Sun Java System Calendar Server 6.3 uses this protocol. Unfortunately, timing is everything. When the dot-com bubble burst, work on WCAP fizzled out. The result: Vendors went back to using their proprietary protocols.

Luckily, the situation did not remain the same. Though it took awhile, a new idea emerged to extend the WebDAV protocol to provide calendar specific support. The result was CalDAV and is documented in RFC 4791.

Of course, having an open protocol buys you nothing if vendors do not implement it in popular products. That is a big reason why CAP didn't take off. Fortunately, CalDAV seems to have gained enough momentum to stick around, as envinced by the CalConnect industry consortium, whose charter is to make sure CalDAV implementations work together and are widely adopted.

Yes, calendaring "nirvana" might still be a long way off, but we are getting closer with Calendar Server 7.

For more information on Calendar Server 7, see the following pages:

Monday Dec 01, 2008

Calendar Server: Updated cscapture Utility

The Calendar Server cscapture utility collects all parts of Sun Java System Calendar Server environment that are useful for debugging, such as log files, database, host environment, config and more. It will also gather core files and debugger data for core analysis.

An updated version of cscapture (1.1) is now available with the following changes:

  • Detects just the current version of the Calendar Server and not the original version that was initially installed prior to upgrading. The previous way of detecting the version was not ideal and was confusing when reading the summary file.
  • Handles relative path names so it won't include the absolute path in the cscapture tar file. Running ./cscapture /var/crash will not longer cause /var/crash/cscapture-xxx to be present in the tar file. Instead the file path will be relative for more easier untar'ing of the data.
  • Includes the system messages files from /var/adm in the cscapture archive.
  • Uses the version 3 of the pkgapp script. This has been included with cscapture v1.1 for recommended use.

    Get the updated cscapture utility here: http://www.sun.com/bigadmin/scripts/sunScripts/SUN-GDD_calendar_cscapture.tar.gz

Friday Jun 13, 2008

Calendar Server 6: Long Awaited Patch

A new Calendar Server 6 patch was made available this week on SunSolve. Patch IDs are:

  • Solaris OS: 121657-28
  • Solaris x86: 121658-28
  • Linux: 121659-28

This is the first patch since -25, when the l10n requirements were unified. If you use non-english l10n patches, you now no longer need them. However, be sure to read the README before installing this patch.

And, if you are patching a Calendar Server deployment on Solaris x86, you must read the README before upgrading for a required procedure. This procedure is required only for x86 deployments. If you are running Calendar Server on SPARC OS or Linux, you do not need to follow this procedure. You need only perform this procedure one time. Following is the applicable text from the README:

CR 6642958 - Bad data representation with 121658-19 patch in x86
version of 6.3 calendar server (x86 ONLY)
With 121658-20 and later, calendar server uses new berkeley db library
which is incompatible with the db created by earlier versions. In
order to use the DB created by 121658-19 (or prior) with this patch,
the data needs to be updated by following the below procedure.

1> Make sure the calendar installation is 121658-19 or prior.
2> Take a copy of the current DB
3> Check to make sure the DB is in good condition by running db_verify
and csdb check
4> Dump the data using db_dump
	Set LD_LIBRARY_PATH to /SUNWics5/cal/lib
	eg: ./db_dump -r -f /var/opt/SUNWics5/dump/ics50alarms.db.txt
	Do the same for all the DBs.
5> Apply this patch (121658-24 or later)
6> Load the data dumped in the above step to the DB files using the
cs_dbload provided in this patch.
	Set LD_LIBRARY_PATH to /SUNWics5/cal/lib
	Run cs_dbload to load files dumped in step <4>
	eg: ./cs_dbload -f /var/opt/SUNWics5/dump/ics50alarms.db.txt
	Do the same for all the DBs
7> Run csdb check or csdb rebuild on the db files created in the above step.

Reporting about Unified Communications Suite Documentation, including news, Comms 101, documentation updates, and tips and tricks.


« August 2016