[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Back to emacsclient/server

From: Ted Zlatanov
Subject: Re: Back to emacsclient/server
Date: Tue, 24 Oct 2006 16:36:15 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux)

On 24 Oct 2006, address@hidden wrote:

>> From: Ted Zlatanov <address@hidden>
>> Date: Tue, 24 Oct 2006 01:02:18 +0100
>>> That sounds like a huge overkill to me.  Let's not forget that
>>> emacsclient is first and foremost for _local_ connections, and these
>>> hardly justify SSH.
>> Oh, I understand that.  Local IP connections are generally much faster
>> than external IP connections.
> I meant ``local'' as in ``on the same machine''.  No IP connection is
> needed.

Yes, I understand that.  Really.  Since SSH is a TCP protocol,
obviously a TCP/IP connection would be needed if SSH was the transport
mechanism for emacsclient-style interactions.  Since I'm suggesting
SSH specifically, I'm implicitly suggesting that emacsclient should go
over TCP/IP instead of a local connection (socket, for example).

>> There are performance and memory hits, yes, but they are minor
>> compared to the gains I listed earlier.
> What about the overkill of writing a much more complicated code in
> Emacs?  That was what I was talking about.

1) Are you sure it's much more complicated than the existing
   emacsclient+emacsserver combinations?  I think it's a worse, but
   not unjustifiably so.  The OpenSSL libraries do a lot of the hard
   work.  Emacs would not have to implement the full OpenSSH
   functionality, and it does not have to deal with much of the code
   that makes OpenSSH complicated: user/group logins, file security,

2) Please consider the gains from a SSH approach: no special
   emacsclient, secure authenticated connections, etc. as I listed
   already.  Don't discard a suggestion just because the code it would
   engender is more complicated.  Take security, user convenience, and
   future gains (e.g. automating Emacs remotely over TCP/IP) into


reply via email to

[Prev in Thread] Current Thread [Next in Thread]