Comment 4 for bug 710491

On Monday 31 January 2011, you wrote:
> Without knowing the client code, just food for thought.
>
> I suspect it could be possible (but most likely not that simple) to take
> the client, keep the "framework relevant part", and switch the graphical
> frontend to an xml rpc server, thus creating an xml rpc "proxy"
> observing consistent rules and procedures.

I'm afraid what you say is far from the current situation.

And the discussion is not at all about XML-RPC (bad title), but about the fact
that we have RPC (as in remote _procedure_ calls) rather than remote _session_
calls.
Think of HTTP/1.1 and the merits that stateless connections have brought to
it. At the same time, those stateless connections meant that all form data
needed to be carried back and fourth from the client. And then, various
workarounds where invented, such as the cookies, sessions, even total
circumventions like AJAX-backed full javascript ORMs in the http client..

Here, we're talking about solving some of the deficiencies of the current
design, with the least possible intervention to the rest of the framework[1].
It will certainly need good thinking..

[1] I personally like the fact that our RPC is somehow free and we can, for
example, restart the server without destroying a client's session.