[Openmcl-devel] Swank stability [Re: A plug for nx1-combination-hook]

[Terje Norderhaug]

On Sep 10, 2009, at 12:23 PM, Daniel Weinreb wrote:
> Terje Norderhaug wrote:
>> On Sep 10, 2009, at 10:14 AM, Raffael Cavallaro wrote:
>>> On Sep 10, 2009, at 11:52 AM, Daniel Weinreb wrote:
>>>
>>>> One technological thing I'd like to see if to make
>>>> the Slime/Swank protocol be documented and
>>>> stabilized
>>>
>>> sorry to be pessimistic, but I get the strong impression that it  
>>> will
>>> be an extremely frigid day in the nether regions when Slime becomes
>>> stable, or, as someone else has put it:
>>
>> The Swank server protocol (ignoring the emacs Slime  
>> implementation)  has been reasonably stable lately. There is a  
>> flip-side to the  stability issue, namely that it is possible to  
>> introduce changes to  make Swank work better for alternative  
>> clients than emacs/slime. My  recent suggestions may have been the  
>> cause of most disruptions lately...
>>
> There are many cases in many architectures in which it's necessary  
> or desirable to design an interface standard so that (a) not  
> everybody has to upgrade simultaneously when changes are made, but  
> (b) it's possible to make improvements.  For something like the  
> Slime/Swank protocol, it would be best to use the good techniques  
> that have been developed. One simple thing is to use versioning.

Agree. My statement in the previous email should not be taken as an  
endorsement of the current practice of having daily new versions and  
refuse to make official releases (the last one was several years  
ago). Even if it fits me well at the moment as I am working on new  
swank clients and benefit from being able to introduce changes to the  
protocol.

> At least make it possible for a client, such as Slime, to find out  
> which version of the Swank protocol is supported by a particular  
> runinng Common Lisp.  Keep the initial part of the protocol, the  
> part needed to get to the point where you find out the version  
> number, as simple, and as likely to be upward-compatible in the  
> face of changes, as possible.

Finding out the protocol version early on is supported in Swank as  
is. After connecting to the swank server, the client can send a  
request for (SWANK:CONNECTION-INFO) immediately after presenting the  
optional secret/password, and will get back information about the  
Swank version in the form of a date string:

:VERSION "2009-08-19"

Still, better practices is needed as we get beyond Swank being used  
with a single instance of Slime+emacs running on the same computer as  
the target Lisp system.

> Make it easier for clients to support multiple versions, by making  
> new versions be supersets of old versions, where possible.  Things  
> like that. It's not very hard to do, but it requires a bit of care.