custom reader and custom rpcs

[Helmut Eller]

On Sun, Oct 20 2013, Alexander Popolitov wrote:

> Hi everyone!
>
> So, here is my proposed enhancement to swank (see patch-file in the
> attachment).
> The idea is, that executing arbitrary code on the lisp core, which
> swank allows by default, is not always
> desirable.
> Hence, patch does following things:
> 1) Add SWANK::*READER* variable, which, when bound to a function when
> calling SETUP-SERVER, causes
>     this function to be used when reading forms in SWANK-RPC::READ-FORM
> 2) SWANK::DISPATCH-EVENT's DESTRUCTURING-CASE is substituted by more
> flexible lookup in the hashtable.
>     If SWANK::*VALID-RPC* list is bound to new value when calling
> SETUP-SERVER, then in this particular
>     server only those new RPC's will be active.
>
> 1st change is useful, I think, not only for securing the reader in a
> way that I did in my CL-SECURE-READ system,
> but also if you actually want learn SWANK talk some non-s-exp-based
> protocol.
>
> So, what do you think?

I think SLIME is a tool for developing and debugging Lisp code and
because of that security is not our priority.  E.g. I don't even have a
~/.slime-secret and I think that only few people bother to create one.
Potentially improved security is not a sufficient argument for me.

I'm also not a fan of making SLIME super flexible. Especially if that
flexibility is not actually used and regularly tested.  Usually testing
becomes more difficult with more flexibility.

On the actual code: I don't think that we want to COMPILE our code at
runtime. Using a hashtable instead of DESTRUCTURING-CASE might be
reasonable, but it also has it's downsides, e.g. it needs a new global
variable for the hashtable.

There are also some situations, e.g. in the debugger, when some RPCs are
processed selectively and others are queued.  Making those situations
table driven is probably difficult and possibly even harder to
understand than what we have now.

Helmut