[slimpl] some comments about vim internals

[Eirik A. Nygaard]

On Fri, Mar 03, 2006 at 09:38:26AM -0800, Brad Beveridge wrote:
> On 3/2/06, Peter Seibel <peter at gigamonkeys.com> wrote:
> > to debug a problem. Or, if there' a big pile of Common Lisp code that
> > you don't want running in your actual server, you could have a set up
> > like this:
> >
> >    +-------------+      +----------------+     +------------------+
> >    | Editor,     |<---> | SWANK FRONTEND |<--->| Your server with |
> >    | e.g. Emacs, |      | CODE written   |     | minimal SWANK    |
> >    | vim, AJAX   |      | in Common Lisp |     | protocol core    |
> >    +-------------+      +----------------+     +------------------+
> >
> > where each box is a separate process. In a normal development
> > environment the two Common Lisp processes could be merged while
> 
> I like this approach.  How many people here would be onboard for this
> kind of architecture?  I imagine that initially we would not try to
> reduce the current swank core at all, and simply (ha!) move the useful
> Slime stuff into a Swank frontend module.
> Would we do something like
>   - don't change Swank backend at all right for now
>   - write a Swank frontend in CL that talks over a socket to the Swank core
>   * should use the existing Swank portability layer for sockets and threads
>   * Swank frontend should expose a nice interface that gives us easy
> access to common debugger functions
>   - write modules that live within the Swank frontend image and
> communicate with editors, ajax, whatever.
> 
> I like Peter's idea a lot
>  1) We get to write the bulk of the code in CL
>  2) It is possible that the Slime guys will like the changes & keep them
>  3) We can write a lot of code that is editor/usage agnostic
>   4) The code that talks to an editor can be very thin, with most of
> the work just being passed to the Swank frontend and getting results
> back.

This sounds to me alike a good approach, having a separate layer for the
communication gives us the advantage of not binding this entire project into
vim. Which then again can lead to more contributors to at least the swank
frontend code.

Also being able to then push changes back into slime will be a huge advantage.
Both with keeping code in sync, but it will also yield a more connected code.
 
With a stable API for the frontend it will require changes in just one place if
swank changes instead of in all the projects that uses swank. This ties in with
my note about more people might come working on the frontend. This being an
advantage for all sides.

With regards to the security concern having a minimal swank backend it great.
Less code that needs auditing, fewer errors that can be made and so on.

What I really like about this approach is definetly the abstraction from the
user-seen frontend.

-- 
Eirik Nygaard