acmeattic-devel team mailing list archive

[Karthik Swaminathan Nagaraj <nkarthiks@xxxxxxxxx>]

At this point, it looks like we need a flexible, efficient Infrastructure
that can handle API methods:

   - Server Web Application API (as in
here<http://nkarthiks.info/acmeattic/index.php?title=Server_Web_Application_API_Proposal>
   )
   - Client daemon API (as discussed in the previous email thread)

A single infrastructure can serve both these purposes, though the scale and
usage are different. I feel that code reuse here is better, because we
definitely need an architecture like this for the Web API and I do not
really see the need for a full-fledged object interface provided by Pyro
(aren't just methods sufficient?).

Why not use something currently available?

   - PyRO uses the pickle library and is hence avoided (for language
   independence).
   - XML-RPC is slow and serialization is lengthy
   - The transport libraries provided with Thrift do not support SSL
   (Incidentally there is a Twisted plugin for the Thrift transport)

How is this going to be implemented?

   - Twisted is going to provide the TCP layer (SSL can be applied here
   easily)
   - A common library of method prototypes is available to both the server
   and client.
   - Server implements the methods, and also listens for calls
   - Clients calls are serialized (using Thrift) and sent to the server
   (sanity checks will be made at the client)

In the special case of a middleware serving the API, the middleware handles
connection setup, and acts as the middleman for passing method calls and
replies (between the client daemon and core request processor(CRP)). Twisted
still handles the client networking (HTTPS client).
I am still undecided about how the Middleware and CRP interact - this could
be a simple TCP connection, where the Middleware appends the user data along
with each request to the CRP and serves the returned reply. *Django* guys -
do you think this is possible? Handling concurrent HTTPS connections, and
routing each of them to the CRP and serving the replies back to the client.

For communication between client daemon and UI, we will have an
unauthenticated connection on localhost with the daemon serving the API to
the UI. I say this is smaller in scale because there is no actual transfer
of huge objects such as files.

I'll write this up on the Wiki, but wanted to get a feedback from you guys.
Do you think this commonality is worth exploiting?

-- 
Karthik