On Jan 16, 2010, at 12:08 AM, Helmut Eller wrote:
- Terje Norderhaug [2010-01-16 03:43+0100] writes:
I think it is time that we factorize out swank's low level rpc layer into a new swank-rpc module that deals with how events are encoded and passed between the client and server.
I have enclosed a draft of a new swank-rpc module for the project. Almost all of the code is extracted directly from the swank.lisp file of the slime-2010-01-15 distribution. It can be included with no disruption to SLIME.
The module act as a specification of the event passing protocol, facilitating alternative swank implementations such as on clojure and scheme. It can optionally validate the input to ensure that the events are consistent with the protocol.
I don't see the point of this exercise. Obviously people have written servers and clients whitout our help, i.e. it's not terribly hard to figure out how Slime works. I bet that decoding the wire syntax was one of the easier parts.
I have a bit experience with reverse-engineering the swank protocol from implementing the MCLIDE swank client. It should be more straight- forward.
The slime protocol is undocumented. The project leaves the implementation to act as the specification for the swank protocol and wire syntax. Yet the swank.lisp module is overly complex. To better act as a specification, it would benefit from separating out the lower layer of the RPC protocol from the swank server specific message handling.
It is also significant that the proposed swank-rpc module can be reused beyond the swank server. Currently I am maintaining equivalent code as part of the MCLIDE swank client. It would be better if the same module could be shared between clients and servers.
Are there any good reasons *not* to factorize out the wire syntax and RPC encoding from swank.lisp? I'd be glad to do the remaining work.
-- Terje Norderhaug terje@in-progress.com