Release Notes Version 0.0.1EA

27th August 2003

Overview

IMPORTANT: DO NOT USE THIS RELEASE ON REAL DATA OR AN OPENGROUPWARE.ORG INSTALLATION THAT IS IN PRODUCTION USE. THIS RELEASE IS PURELY AIMED TO GIVE DEVELOPERS A LOOK AT THE API AND ALLOW THEM TO CONDUCT SOME INITIAL STEPS WITH THE API. The 0.0.1EA Release of the JOGI API is the initial release of the ogojogi project. The "EA" at the end of the version number means "Early Access", to show that this release is not yet fully usable and just aimed to give developers a look at the project. The API is not yet feature-complete, but the design is many areas finished. This release is supposed to allow early adopters to get experience with the library and (hopefully) to provide feedback for the developers (especially feedback concerning the design would be appreciated [hint,hint]). Developers interested are advised to also monitor the CVS repository, as the versions in there are always more up to date. See the download section on the ogojogi website for info on the CVS repository (if you are to lazy to go there: please only checkout the ogojogi Module in the CVS; the others are failed attempts at using CVS and our website).

Demos

There is currently only one tiny demo app that is just capable of getting the system time of the server. Another experimental demo is a modified version of the Skyrix Java client (written by an Skyrix employee). You can download that from the download page of the ogojogi website (or the Sourceforge download pages for the project). This features a simple GUI that allows you to access and create Appointments on a server. This client only works with JDK 1.4.*.

Requirements

The code was written and tests performed with the Sun JDK 1.3.1 and JDK 1.4.2. This might change in the future. If we see the need for any 1.4.* specific packages, JOGI will be 1.4 only.

CAUTION: JOGI was only tested with the OpenGroupware.org version that was released on a bootable (Knoppix) CD. The image of this CD is available online (as far as we know). JOGI hopefully works with the OpenGroupware.org packages that can be downloaded, but that has not been verified yet. If you succeed to get JOGI to work with those packages please notify us (either on the MailingList or just contact one of the developers).

Not implemented

Some of the functionality is not yet implemented. One reason is that Opengroupware.org was only released in mid-July (which means only 6 weeks between that and this first release). So there was just no time for some of the functionality yet.

Another reason for the incomplete state is that a certain amount of reverse engineering was required to hook up to the OpenGroupware.org XML-RPC daemon. There is extensive documentation (see the Links section on the JOGI website) for the XML-RPC functions, but there are some things missing and a few things unclear. So, we got to spend quite some quality time with a network sniffer to see what the XML-RPC daemon actually sends back.

To make a long story short, here are the omissions for this release:

net.sourceforge.net.ogojogi.jogi.ogo.Mail: this interface is defined, but it is not yet backed by an implementation, as there are still some design considerations to be considered (specific: how to create the mail).
Job functionality and ToDo lists: the Job and JobManager classes are implemetned, but some Job-related code is not yet implemented. Eg. it is not yet possible to access an OpenGroupware.org users ToDo-Lists (again: design considerations; we are still unclear where to put those methods). These problems should be resolved in the next official release, but you might want to watch the HEAD of the CVS for changes.
net.sourceforge.net.ogojogi.jogi.ogo.Project (parts): the insert method does not yet work as OpenGroupware.org returns some weird results to our request. As this is not (we think) essential functionality, we left this for the next release. Also: the {load|save|new}Document methods have not been tested yet and might just cause a nuclear meltdown in a power plant near you... or not, who knows.
Update?: Well, that is a design issue, that is still waiting to be resolved. All objects fetched from the server are cached on the client, and read accesses to its properties do not cause an XML-RPC call to happen. One problem with this approach is that changes on the server are not reflected on the client if those changes happen after the object was fetched. There is no simple way to find out about changes on the server and polling for changes might get extremely messy and anything but efficient. If this is a problem for your application, you might want to fetch() the object before accessing the data. Getting an object with the fetch() method updates its instance on the client. CAUTION: fetch always transmits the whole data structure for objects; as some objects (Person,Enterprise) are rather big, that can prove to be a bottleneck if you do it too often. If you know, that no one else is likely to change the data on the server, you can safely ignore the stuff.
WHAT ELSE?

Tests