understanding xmlRpcSerializable and new javascript ReferencableObject "sync" method, etc

[Colin Walters <walters redhat com>]

Hi,

So I started late yesterday on a big change to clean up a lot of the
code.  On the server end, there was a lot of duplication between the
XML-RPC way of getting information about an object and the JavaScript
preloading.  On the client end, we had multiple constructor paths and
special casing to handle the preloading case, and various separate
XML-RPC calls just to retrieve a few object ids from e.g. a discussion.

On the server end for example, a number of objects had two ways to
serialize; one for XML-RPC, and another for JavaScript.  Take
ClosedComment.  It had a special inner class ClosedComment$Contents
which was exported via a special XML-RPC method
getClosedCommentContents.  It also manually serialized stuff in its
toJavaScript() method.  

What I did on the server end is implement a new xmlRpcSerializable
interface; objects can serialize to a generic Map of strings to objects.
We now have a dumpObjects XML-RPC call which serializes the requested
objects and sends them back.  However, we can take this same object
serialization and turn it into JavaScript code.  So now instead of each
object having to know about JavaScript, it's just ActiveTopic which
recursively serializes all the objects it contains and turns that big
serialization into JavaScript.

On the client end, I *really* wanted to kill the multiple constructor
path, where various constructors took a final "contents" argument which
if unset meant it had to do a separate initFromContents path.  What I
did instead is have the server, during preloading, fill out a
referencableObjectPreCache array which maps object id -> serialized
JavaScript.  Then inside each constructor, instead of taking a final
argument, we simply see if our object is already cached, and if it is we
init from that.

The other *nice* thing about this change is that I could unify
initFromContents and the various update() methods.  So what I did is
have ReferencableObject have a default version of "update" which simply
asks that the object be dumped from the server via XML-RPC, and call the
JavaScript "sync" method if defined.

The key idea here is that if an object is relatively bounded in size
such as a Topic or Discussion (like in those cases it's basically just a
container for object references), there's no point to doing separate
XML-RPC roundtrips for retrieving a list of discussions versus
whiteboards versus statements.  Now whenever the topic changes we just
dump all of those in one go and refresh.

I hope this all makes sense, and I also hope I didn't introduce new
bugs :)