[slime-devel] swank-rpc module
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. As the swank event passing protocol is orthogonal, Common Lisp swank clients like MCLIDE can share the swank-rpc module with the project instead of duplicating the code. -- Terje Norderhaug terje@in-progress.com
* 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.
As the swank event passing protocol is orthogonal, Common Lisp swank clients like MCLIDE can share the swank-rpc module with the project instead of duplicating the code.
Doesn't sound very convincing. The way you did it, the client would need to have a swank and swank-backend packages. Helmut
On Jan 16, 2010, at 12:08 AM, Helmut Eller wrote:
* Terje Norderhaug [2010-01-16 03:43+0100] writes:
As the swank event passing protocol is orthogonal, Common Lisp swank clients like MCLIDE can share the swank-rpc module with the project instead of duplicating the code.
Doesn't sound very convincing. The way you did it, the client would need to have a swank and swank-backend packages.
It is not the case that a client using the proposed swank-rpc module will need to have the swank and swank-backend modules. The swank- rpc.lisp module loads into Common Lisp without such dependencies. The only function left undefined is the safe-backtrace invoked by the error condition, but eliminating that dependency is trivial. As is, the swank-rpc module provides a general purpose RPC message passing layer for Common Lisp, and can be used independently from the swank server. -- Terje Norderhaug terje@in-progress.com
Helmut Eller <heller@common-lisp.net> writes:
* 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'll kind of hijack this thread now. Sorry about this. In the thread about generalizing buffer context (which I haven't come around doing yet, but I still intend to), you said that it'd cleaner for a general rpc server to get rid of the implicit buffer context. I agree with that, but I didn't see the point of how SWANK is, or is supposed to be, a general rpc server. If it's supposed to be, I share sentiment with extracting that bit (won't come as surprise to you :-)) -- if it's not supposed to be, then why can't we have generalized, but still implicit, buffer context passing? -T.
* Tobias C. Rittweiler [2010-01-16 10:41+0100] writes:
If it's supposed to be, I share sentiment with extracting that bit (won't come as surprise to you :-)) -- if it's not supposed to be, then why can't we have generalized, but still implicit, buffer context passing?
Implicit context will most likeley be done with dynamic variables, which is sometimes problematic. Also sending context with rpc's which don't need the context is, well, not needed. Helmut
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
* Terje Norderhaug [2010-01-16 11:41+0100] writes:
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.
I'm no friend of making something more general than it needs to be. Slime is also not a library or toolkit; it's an application. I you feel that this is an improvement then commit it. Helmut
On Jan 16, 2010, at 5:18 AM, Helmuth Eller wrote:
* Terje Norderhaug [2010-01-16 11:41+0100] writes:
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.
I you feel that this is an improvement then commit it.
Done. The next step is to eliminate the redundant code from swank.lisp and load the new swank-rpc module before swank.lisp. -- Terje Norderhaug terje@in-progress.com
participants (4)
-
Helmut Eller -
Helmuth Eller
-
Terje Norderhaug -
Tobias C. Rittweiler