transfer and cache versioned object file

Question

Problem definition:

The project setup uses GWT on the client side and Spring on the server side There is an object tree of 100 objects. The object describes a complex config file that is linked to one user. This object has to be persisted on the server side and can be requested by the client. Both client and server can access all methods and fields in the Object. Once requested by the client, this object tree is cached. The object can be modified by the client and server. If the file is modified by the server, the client downloads the new version. It should be easy to add extra functionality to the config object i.e. increasing the version number and adding objects to the tree. The config file is a project file that saves all changes the user did to make the project as it is. The config file is altered regularly (every 3 seconds) by the user. Compare it to for example a Gimp project / PowerPoint file.

Current architecture:

The server stores the config file in an XML format. When the config is requested, this is converted to a Java object that is send from server to client using the RequestFactory (GWT). The client can modify that object and changes are send to the server. When the client is done, the server saves the new object by replacing the old XML file. The client also caches this Java object using the HML5Storage (GWT). The 5MB limit is not a problem. When a new version of the object is created at the server, e.g. a new object type is added to the tree, the client downloads the new object tree and discards the old one.

Questions:

• Is this a good way to approach the problem?

Maybe I should send the XML file directly from the server to the client on the initialisation. Modify this file by the Client and send it back to the server when he is done. The client could store the XML file as is in the HML5Storage. Maybe there are some odd choices someone can point out.

• Is there a better format to store this data server side instead of XML?

I chose XML because it has good libraries that allow mapping of Java objects to an XML file and it allows adding additional functionality easily. Also this data is linked to one user and the data isn't used otherwise. So it seams a bad idea to store this in a relational DB and combine all those objects in a tree (this would take long to assemble).

• Is the RequestFactory also good for the initial download of the object tree?

I've read cases where the RequestFactory could take a long time to download a big list of objects. (x 10 in time compared to RPC).

If you made it to this point and something isn't clear, I'm happy to add extra details where needed.

Answer 1

Is this a good way to approach the problem?

Preloading the object on login is a good idea. A better one would be to break the object tree into small parts and load each of them on request, when the user need to edit that specific part of the config. This assumes that instead of providing a single view to edit all the config properties you somewhat "organized" it into many separate forms, which will request part of the config they need only when it is appropriate. It'll need some work but your architectur be more maintainable if that object changes later.

I don't think you are doing it properly since you transform your object tree (I understood it was some big Java object) to XML, instead of sending that object to the client right away. GWT RPC will handle the serialization/deserialization (actually by using JSON instead of XML). Isn't it easier to manipulate a Plain Java object than XML (even with good libraries) ?

Is there a better format to store this data server side instead of XML?

I generally use JSON. It also has good libraries. I only use XML when a human need to read the file directly.

But I don't see why you would need either of them. GWT RPC mechanism will serialize your java object into json automatically. Just provide a "shared" object and (if needed) a converter to convert your object tree to its shared form and back.

Is the RequestFactory also good for the initial download of the object tree?

As XML takes more space than JSON and that manipulating XML is slower than manipulating a java object, I would actually advice to use RPC.