<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Scott McKay wrote:
<blockquote
cite="mid:917E224C-10E8-423C-8574-656C6A28065F@itasoftware.com"
type="cite">
<pre wrap="">On Dec 19, 2010, at 10:46 AM, Daniel Herring wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Sun, 19 Dec 2010, Scott McKay wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Dec 17, 2010, at 4:57 PM, <a class="moz-txt-link-abbreviated" href="mailto:aerique@xs4all.nl">aerique@xs4all.nl</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 17 dec 2010, at 22:15, Eli Naeher <a class="moz-txt-link-rfc2396E" href="mailto:enaeher@gmail.com"><enaeher@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Right now I usually have (under screen) one instance of Emacs for
personal projects (for which I try to use the latest Slime and Swank)
and one for work (where they do not get updated so frequently), and
sometimes I need to start a third instance if I am doing work on an
older maintenance branch of the software. It seems like there should
be a way to switch between Slime versions within the same running
Emacs, but I have yet to figure it out.
</pre>
</blockquote>
<pre wrap="">Not a direct question to Eli, but why is Slime so version specific
anyway?
</pre>
</blockquote>
<pre wrap="">Ya have to wonder if Slime/Swank should be used Protocol Buffers
or Thrift to do their RPC. These both support versioned protocols,
and it would be great to have a CL binding to Protocol Buffers.
</pre>
</blockquote>
<pre wrap="">As I understand it, the wire protocol is generally the stable part of Slime. The RPC aspects (what the server commands do) is what has deep implications and changes frequently.
</pre>
</blockquote>
<pre wrap=""><!---->
But what I am saying is, use something that supports versioned
wire protocols, and instead of willy-nilly changing the existing
API frequently, change it in constrained ways, increment a version
number, and use a new version of the wire protocol.
Yes, it's work.
</pre>
</blockquote>
Slime and Swank already check the versions when they start. It's<br>
part of the defined wire protocol. Well, actually, it's defined<br>
as part of the convention that's always used between Slime and<br>
Swank. So if you want to use Swank from a non-Slime client, you<br>
ought to put this in yourself.<br>
<br>
Swank has a global variable named *swank-wire-protocol-version*.<br>
When Slime sends the connection-info command, Swank sends back a<br>
bunch of info including this value. Slime checks whether this<br>
equals slime-protocol-version, and if not, asks you "Protocol<br>
version mismatch. Continue anyway? " with a yes or no answer.<br>
<br>
Both Slime and Swank get the protocol version by opening the file<br>
ChangeLog file and getting the first token in it, which is<br>
something like "2007-12-20".<br>
<br>
The important issue is *when* they do it.<br>
<br>
In Swank, it is done at the time that the swank-loader.lisp file<br>
is loaded. Under normal circumstances, i.e. when you start up a<br>
Common Lisp instance that Swank isn't already loaded into, it<br>
happens when you start up Slime, beacause that starts up Swank.<br>
<br>
In Slime,<br>
there is a top-level form:<br>
<br>
(setq slime-protocol-version<br>
(eval-when-compile (slime-changelog-date)))<br>
<br>
I think this means at the time that swank.el is compiled into<br>
swank.elc.<br>
<br>
The ChangeLog file is supposed to be updated with a new entry at<br>
the front every time a change is made to either Slime or Swank.<br>
So the code is very conservative about versions. You don't have<br>
to ask whether the change you just made would alter the protocol.<br>
As Daniel Herring pointed out, even if all the functions and<br>
arguments remain the same, their effect might differ from one<br>
version to the next in a way that matters to the client.<br>
<br>
The downside to being so conservative is that you are forced to<br>
keep your Slime and Swank aligned any time you make a change. If<br>
you have Swank pre-loaded in your image, the client must use<br>
exactly the same version of Slime, or else subvert the checking<br>
mechanism (by altering the ChangeLog file) or something.<br>
<br>
At least it looks that way to me.<br>
<br>
-- Dan<br>
<br>
<blockquote
cite="mid:917E224C-10E8-423C-8574-656C6A28065F@itasoftware.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">[aside] Protocol buffers are an unnecessarily complicated reinvention of the wheel. If the big G wasn't using them, everyone would be using one of the preexisting formats (e.g. XDR). See MapReduce for a related theme. IMO, a binding to Apache Camel or OpenSplice DDS would be much more interesting.
</pre>
</blockquote>
</blockquote>
(Although this is an interesting topic, I suggest<br>
that we not get into this on the pro-lisp list.)<br>
<blockquote
cite="mid:917E224C-10E8-423C-8574-656C6A28065F@itasoftware.com"
type="cite">
<blockquote type="cite">
<pre wrap="">
- Daniel
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
pro mailing list
<a class="moz-txt-link-abbreviated" href="mailto:pro@common-lisp.net">pro@common-lisp.net</a>
<a class="moz-txt-link-freetext" href="http://common-lisp.net/cgi-bin/mailman/listinfo/pro">http://common-lisp.net/cgi-bin/mailman/listinfo/pro</a>
</pre>
</blockquote>
</body>
</html>