Newsletter #2, December 2003

by murphee

And again it's time to take a peek behind the scenes of the JOGI Team.

Current situation

Well, well, well... if you've read the previous newsletter, you might have noticed... the planned releases have not happened; the release dates were a bit too optimistic. Turned out, university and the occasional job, are more demanding that I had initially thought. So, we didn't return from the leave we had taken from the JOGI project... until a couple of weeks ago. Well... you live and learn; and one thing I learned, was to allow for more time between releases.

Current developments - Error Reporting

Walter, our developer in Vienna, was the first to recover from the university workload, and has taken it upon himself to implement proper error reporting.

The previous JOGI versions, always silently swallowed exceptions, or simply reported them to System.out. This was not acceptable behaviour for a library that works over the network all the time. All kinds of operations can fail with I/O, and with networks, it is even worse.

So, it was decided, to change the JOGI interfaces to contain throws clauses for all potentially dangerous methods. As just about any method in JOGI uses (or may use) a network connection, this means that just about any method now can potentially throw a checked exception.

The use of checked exceptions (= exceptions that must be caught or declared in the throws of using code) versus unchecked exceptions was debated on the Mailing list. The basic reason for going with checked exceptions was the java.io.* and java.net.* APIs (among others). Those APIs also use checked exceptions for operations that can easily fail. One of JOGIs basic design principle is to be a "Java API", ie. it should feel "natural" to experienced Java developers. So, as the Java APIs that deal with I/O force explicit handling of exceptions, JOGI follows the same premise.

This feature will be available in Release 0.0.4EA; proper documentation for the new error reporting will provided (as always, in an updated UserGuide).

Future releases

Oh well... lets try that again. Maybe this schedule will actually work out. The next release will be 0.0.4EA with some changes, with 0.0.5EA with some changes to the interface (interchangable caching/updating policies,...).

0.0.4EA

Planned: end of December 2003

This is mostly a maintenance release, ie. fixed bugs and more implemented functionality. The planned changes

• Error reporting with Exceptions
• Logging switched to log4j

0.0.5EA

Planned: well... 2004

With this release, the 0.0.4EA code will be refactored, to improve code quality. The current code contains some hacks and a lot of copy&paste nastiness that needs to be removed. After that is done, new features can be incorporated. The planned changes

• Pluggable Cache/Update policy to allow for more flexibility
• Code quality improvements
• Probably more implemented functionality

Newsletter #1, October 2003

by murphee

This is the first issue of the OGO-JOGI newsletter, an irregular status report on what is going on behind the scenes of the JOGI API.

What happened so far...

Well, after starting coding and design in early august, we released an 0.0.1EA (Early Access) release in late August. This was well received by the OpenGroupware.org developers and it seems like there is a steady interest in JOGI (at least the Sourceforge statistics information shows that people are visiting the website and downloading the package...).

The developer team has also grown by 50%, brining us to a staggering total number of developers of: 3. Our new developer is Walter Christian, an austrian student at the Technical University of Vienna (see our About page).

Current situation

The current 0.0.3EA release is already usable, but (as the "EA" in the release name implies) is still not finished. We are going to continue development of the JOGI API in the future and already have planned what we want to do with the project... after a short break. As all members of the developer team are students, the start of the new term (beginning of october) means that we are already busy right now. Additionally, I (murphee), also just started at a new part-time job and Andreas (murphee) just moved to the UK to study there for a year, so we are at the moment very pressed for time and can't devote much to the JOGI effort.

BUT, we'll get settled in pretty fast and will take up our work as soon as possible. If you want to know what awaits you, just check out our release plan for the next months.

Future releases

0.0.4EA - Maintenance release

Planned: middle of October 2003

This is mostly a maintenance release, ie. fixed bugs and more implemented functionality. This release was actually planned to go out before our little break from JOGI, but due to a bug report about a possible critical problem in JOGI delayed that. I am currently trying to figure out whether the bug is in JOGI or is some issue in/with OpenGroupware.org. After that has been worked out, the 0.0.4EA release will be published.

0.0.5EA - Feature & Design updates

Planned: early November 2003

We were very glad that we received a lot of response to our JOGI releases. We were especially glad to hear from people that used JOGI and told us about stuff they didn't like and/or what they would like JOGI to be like. This was very helpful, as designing an API like JOGI is particulary difficult, if the target audience is not known.

One major goal now is to increase the performance of JOGI and its memory efficancy. Not necessarily because JOGI is particularily slow now, but because of the current design, which was mostly aimed at interactive applications that keep a lot of the data in memory all the time (like GUI Organizers,...). As it turns out, that is not what many people want to use JOGI for; they either want to fetch data from an OpenGroupware.org installation or insert data into one. With the current caching mechanism, this is feasible, but not in an efficient way. The "cache-everything" policy causes unnecessary memory use, and the "write-through" approach to data manipulation (eg. calling one of the setXXX methods on an data object,...) causes a lot of unnecessary network traffic.

This problem will be solved by introducing a pluggable caching policy. This will allow the user to decide on his own, when to cache an object and when to send updates (ie. when an setXXX method is called). The design for this is basically done, but as always, some issues just make this thing more difficult that it looks, and thus take some more considerations (think: threadsafety, data consitancy, inuitivity of the design, ...).

Other problems that were reported were the basically non-existant error reporting with JOGI. JOGI does not throw any exceptions, neither when problems in the transport (XML-RPC) occur or when OpenGroupware.org throw an exception. This needs to be changed. BUT, of course, it's not as easy as it sounds. The questions that come up are: checked or unchecked exceptions? Throw JOGIExceptions for anything that occurs, simply rethrow the exceptions that were caught by JOGI or ... well something else?

And, there is more; if you're interested, see the TODO.murphee file in the CVS HEAD for details.