It may seem that progress on this project has been quite slow during the last few weeks. Partly, this is because progress has been quite slow during the last few weeks. Writing a lot of self-contained code is easy, but as soon as I have to interface with the Eclipse API, each line of code can easily take an hour of poking around in documentation. Another reason for the lack of visible progress is that I’ve spent a few days refactoring and reorganizing the preference pages for EclipseFP. However, these changes aren’t ready yet and are currently parked away in a branch. But I decided not to let work “under the hood” keep me from posting updates!
Nominolo (my mentor, and the author of Scion) and I decided that it was no good to have the Scion server speak different protocols for each type of client that it serves. There were already separate Emacs and vim protocols, each with a different set of accessible commands, and adding and maintaining additional protocols would quickly grow unwieldy.
We therefore settled on one, and only one, protocol that is easy to parse from nearly every language: JSON. As simple as possible, but not any simpler. I threw away my hacked Lisp parser and implemented the JSON-based protocol in EclipseFP.
There are several options for JSON parsing from Java. Two feasible ones referenced from the JSON homepage are org.json (or whatever its name is) and json-simple. org.json uses specialized objects to represent the different JSON types, whereas json-simple uses standard Java classes. Although this sounds simple and elegant indeed, I abandoned json-simple because it does not employ generics, and therefore still requires many typecasts. In fact, neither of the two libraries are very nice and type-safe (because of JSON’s dynamic nature, they cannot be!), but org.json provides many utility methods that save typing out explicit casts.
Apart from simplicity and well-definedness, JSON has another advantage over the previous protocol: it is now possible to test the Scion server through telnet.
EclipseFP GSoC '09 
July 1, 2009 at 01:21
FWIW ECF has a Google Summer of Code project to add REST-style remote services support…including using json as one of the parsers/generators (actually the intension is to support arbitrary serialization, but json is one the project is supporting ‘out of the box’ (other is xml): http://wiki.eclipse.org/REST_abstraction_for_ECF
July 1, 2009 at 02:47
JSON != protocol — it’s just a serialization mechanism. What is the rest (no pun intended) of the story?
July 1, 2009 at 11:35
Scott: REST is, by definition, stateless. Here we have a single server, servicing a single client, so maintaining server-side state is not a problem. In fact, with the stateful GHC API, it would be difficult to get around this.
Oisin: You’re quite right. Well, just as in the old Lisp protocol, the client sends commands to the server, and the server responds. Both the command and the response are serialized using JSON. The actual “protocol” (i.e. the commands and appropriate responses) is custom, still in flux, and currently only defined by the Scion source code.