Java ACAP API

We need more client support. I'm thinking here particularly of Mozilla, but an ACAP Java API would be useful in a number of areas. There are a number of projects on mozilla.org and mozdev.org that would benefit from ACAP. The first thing we need is an ACAP client library. For notes on this, see Dave Cridland's comments below.

Other possible ACAP/Java projects

• The ACAP library could be used as a backend to some of the current Mozilla modules. Here's a partial list of the things that could usefully have ACAP linked in:
  • Bookie: http://bookie.mozdev.org/; this is something which stores bookmarks in a central location. ACAP could be used here
  • wwwampire: http://wwwampire.mozdev.org/; This is another bookmark management system; ACAP could work as a component of this (in the place currently occupied by LDAP)
  • Abzilla: http://abzilla.mozdev.org/; an Address book manager which has LDAP and MAPI on the backend, and could use ACAP
• There's also a Java Webmail that needs ACAP support

Details on the ACAP Java API

When the Cyrus ACAPd was the only ACAP server on the 'Net, and the ACAP standard wasn't yet finished, someone from the Cyrus Project at CMU wrote an ACAP Java API. It is known to be out of date, but may be salvageable. However, it would probably be a good idea to reproduce it with a different license (ie. BSD, LGPL, MPL, or something like that).

The following are Dave Cridland's comments on how a Java ACAP API should be implemented. I would suggest that he's right, because he knows what he's talking about; see his comments below.

 FWIW, my general concept of how ACAP client code could (but perhaps not
 should) work is that you have an object representing the ACAP
 connection, which handles stuff like authentication, etc, and then a set
 of objects for actually getting the data, inheriting from a common base,
 specializing for each dataset.

 You'd also have objects representing each entry, which would then be
 actively used for data access. Contexts would be hidden away in the
 search object, stores would actually be handled by constructing the
 store list in the entry objects, and handing them to the connection
 object to deal with.

 The nice thing is that this translates well to a multithreaded
 architecture, since the connection object can simply wait for stuff to
 send, or stuff received, and dispatch it to "interested" objects.

 Something like, if you like ASCII-art UML:

 +------------+      +-----------+          +---------------+
 | Connection |<-----|  Search   |<---------|     Entry     |
 +------------+      +-----------+          +---------------+
 +------------+      +-----------+          +---------------+
                           A                       A
                           |                       |
                     +-----------+          +---------------+
                     | Bookmarks |O-------->| BookmarkEntry |
                     +-----------+          +---------------+
                     +-----------+          +---------------+

 So Connection handles LOGIN, LOGOUT, and occasional UPDATECONTEXT
 requests when things appear quiet, and dispatching server responses to
 "interested" Search objects. Probably also handles allocating distinct
 CONTEXT names.

 Search takes the dispatches responses, and parses them into a map of
 attribute to value.

 Entry constructs store-lists, hands them to Search objects, which hand
 them to Connection, and the responses come back again. To the
 application, Entry appears like a map, I imagine, with an extra "commit"
 to send pending changes back to the server.

 Bookmarks is a specialised Search, and knows a bit more about what the
 "right" search to do is (In this case, SEARCH "/bookmarks/~/"
 MAKECONTEXT NOTIFY "blah" RETURN ("*") SORT ("i;ascii-casemap" "entry")
 ALL, assuming I remember which way around the SORT goes.).

 BookmarkEntry has handy accessors for the bookmarks attributes.

 The nice thing about this is that the Connection object can hide away
 quite a lot of stuff, including disconnected operation and all sorts,
 while the app itself gets a fairly clean view of the data it wants.

 Oh, Search and Entry classes would have to be concrete, really, so that
 the cost of entry for someone just wanting a quick way to blast some
 simple prefs into a vendor dataset could easily get going.

Dave also kindly found a Java SASL library, but unfortunately that link is now dead. You'll have to find your own.