GNU Emacs: Client/Server

GNU Emacs: Client/Server

[Dhruva Krishnamurthy]

Hello,
 The fact that "emacsclient" does not build on MS Windows platform
 (correct me if I am wrong), we end up depending on "gnuserv"
 functionality. This is *NOT* part of distribution and therefore makes it
 difficult to keep update with changes in "gnuserv" (if there are any,
 recently).

 I was toying with the idea of making the GNU Emacs behave as a client or
 server through command line options or Elisp functions.

(On Microsoft Platform on which I work)
For server:
- Create a server thread which will use some IPC (mail slots or named
pipes kernel object) through which Elist expressions can be exchanged
which can be evaluated by the server

For client:
- Make sure the end point for IPC exists
- Dispatch commands to the IPC channel to communicate with server

Using Kernel objects, we can ensure that only 1 server is running on the
computer.

Could we use the above approach and do away with the gnuserv/emacsclient
dependency?

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: GNU Emacs: Client/Server

[Jan D.]

> Hello,
>  The fact that "emacsclient" does not build on MS Windows platform
>  (correct me if I am wrong), we end up depending on "gnuserv"
>  functionality. This is *NOT* part of distribution and therefore makes 
> it
>  difficult to keep update with changes in "gnuserv" (if there are any,
>  recently).
>
>  I was toying with the idea of making the GNU Emacs behave as a client 
> or
>  server through command line options or Elisp functions.

Are you proposing something like mozilla or xmms?  Where
% mozilla -remote ...

will connect to an already running mozilla process and send the command
to that process.  Or like xmms (a music player), where
% xmms file

will start playing file on an already running xmms process if one 
exists.

Kind of integrating emacsclient in the emacs binary so that
% emacs -remote ...
is basically the same as
% emacsclient ...

	Jan D.

Re: GNU Emacs: Client/Server

[Dhruva Krishnamurthy]

On Thu, 29 Jan 2004 13:03:49 +0100, "Jan D." <jan.h.d@swipnet.se> said:
> 
> Are you proposing something like mozilla or xmms?  Where
> % mozilla -remote ...
> 
> will connect to an already running mozilla process and send the command
> to that process.  Or like xmms (a music player), where
> % xmms file
> 
> will start playing file on an already running xmms process if one 
> exists.
> 
> Kind of integrating emacsclient in the emacs binary so that
> % emacs -remote ...
> is basically the same as
> % emacsclient ...
> 

Yes. Usually, I use the gnucleintw.exe for opening files in the same GNU
Emacs window. For starters, just opening a file in a running GNU Emacs
sprocess would be fine. Slowly, we can extend it to handle features of
"gnudoit" which can send lisp expressions to be evaluated by a running
GNU Emacs process. The whole idea is to make better packaging (as I do
not see any improvement over existing framework of using gnuserv).

with regards,
dhruva

PS: My understanding of GNU Emacs internals is *highly* limited. I can
contribute ideas but I may not be able to do the actual implementation.
Also, I do have MS Windows app dev exp and hence cannot comment on core
platform dependent issues.
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: GNU Emacs: Client/Server

[Kim F. Storm]

> 
> PS: My understanding of GNU Emacs internals is *highly* limited. I can
> contribute ideas but I may not be able to do the actual implementation.
> Also, I do have MS Windows app dev exp and hence cannot comment on core
> platform dependent issues.

That's ok, but if you think in terms of the current mechanisms used by
process.c for network services, i.e. listen, accept, and select, how
hard/easy would it be to add mail slot handling to that, i.e. can you
wait on connections and/or input to a mail slot at the same time
as you wait for TCP connections using select?

Maybe you can show me some W32 code which examplifies how a
multi-connection client and server application mixing normal
processes, network socket connections, and mail slot connections can
be written.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: GNU Emacs: Client/Server

[Kim F. Storm]

"Dhruva Krishnamurthy" <devel@member.fsf.org> writes:

> Hello,
> On 29 Jan 2004 17:18:44 +0100, "Kim F. Storm" <storm@cua.dk> said:
> > That's ok, but if you think in terms of the current mechanisms used by
> > process.c for network services, i.e. listen, accept, and select, how
> > hard/easy would it be to add mail slot handling to that, i.e. can you
> > wait on connections and/or input to a mail slot at the same time
> > as you wait for TCP connections using select?
> 
>  Yes, you can wait for connections in mail slots
> 
> > Maybe you can show me some W32 code which examplifies how a
> > multi-connection client and server application mixing normal
> > processes, network socket connections, and mail slot connections can
> > be written.
> 
> PS: I am not sending this mail to the list, not to annoy people who are
> not interested.

I don't have all the answers (and questions) on this subject, so it
is ok to CC: emacs-devel.

> 
> The code I have written to start a MAIL SLOT Server: It just processes 3
> messages, START, END and FLUSH (I use it to control profiling)

Thanks, but....

The problem with your code is how to mix it with code that must ALSO wait
on normal network receive and process output.  In your code, you have
two waiting-points (as I understand it:)

>     fResult=GetMailslotInfo(g_CRAMP_Profiler.g_h_mailslot,

which I assume waits for connections, and

>       fResult=ReadFile(g_CRAMP_Profiler.g_h_mailslot,

which I assume waits to receive data.


Both of these must --somehow-- be wrapped in such a way that they
become non-blocking operations and/or will function through the normal
"select" call which more or less combines all waiting points for async
processing in emacs into one.  Actually, I'm not sure select is
"normal" on W32, but that's the interface you need to emulate to add
mail-slot support to emacs'.


> 
> //-----------------------------------------------------------------------------
> // ProfilerMailSlotServerTH
> //-----------------------------------------------------------------------------
> DWORD WINAPI
> ProfilerMailSlotServerTH(LPVOID idata){
>   char filename[MAX_PATH];
>   sprintf(filename,"\\\\.\\mailslot\\cramp_mailslot#%ld",
>           GetCurrentProcessId());
> 
>   g_CRAMP_Profiler.g_h_mailslot=CreateMailslot(filename,
>                                                0,
>                                                MAILSLOT_WAIT_FOREVER,
>                                                NULL);
>   if(INVALID_HANDLE_VALUE==g_CRAMP_Profiler.g_h_mailslot)
>     return(-1);
> 
>   // Mail slot server loop
>   DWORD wstate=-1;
>   HANDLE h_event;
>   char msevtname[256];
> 
>   sprintf(msevtname,"CRAMP_MAILSLOT#%ld",GetCurrentProcessId());
>   h_event=CreateEvent(NULL,FALSE,FALSE,msevtname);
>   DEBUGCHK(h_event);
> 
>   while(1){
>     DWORD cbMessage=0,cMessage=0,cbRead=0;
>     BOOL fResult;
>     LPSTR lpszBuffer;
>     DWORD cAllMessages;
>     OVERLAPPED ov;
> 
>     ov.Offset=0;
>     ov.OffsetHigh=0;
>     ov.hEvent=h_event;
>     fResult=GetMailslotInfo(g_CRAMP_Profiler.g_h_mailslot,
>                             (LPDWORD)NULL,
>                             &cbMessage,
>                             &cMessage,
>                             (LPDWORD)NULL);
>     DEBUGCHK(fResult);
>     if(cbMessage==MAILSLOT_NO_MESSAGE)
>       continue;
>     cAllMessages=cMessage;
> 
>     // Mail slot loop
>     while(cMessage){
>       lpszBuffer=(LPSTR)GlobalAlloc(GPTR,cbMessage);
>       DEBUGCHK(lpszBuffer);
>       lpszBuffer[0]='\0';
>       fResult=ReadFile(g_CRAMP_Profiler.g_h_mailslot,
>                        lpszBuffer,
>                        cbMessage,
>                        &cbRead,
>                        &ov);
>       if(!fResult||!strlen(lpszBuffer))
>         break;
> 
>       // Process the message HERE
>       if(!stricmp(lpszBuffer,"STOP"))
>         CRAMP_DisableProfile();
>       else if(!stricmp(lpszBuffer,"START"))
>         CRAMP_EnableProfile();
>       else if(!stricmp(lpszBuffer,"FLUSH"))
>         CRAMP_FlushProfileLogs();
> 
>       GlobalFree((HGLOBAL)lpszBuffer);
>       fResult=GetMailslotInfo(g_CRAMP_Profiler.g_h_mailslot,
>                               (LPDWORD)NULL,
>                               &cbMessage,
>                               &cMessage,
>                               (LPDWORD)NULL);
>       if(!fResult)
>         break;
>     }
>   }
> 
>   return(0);
> }
> 
> The mail slot client: This communicates with the process on the computer
> specified
> //-----------------------------------------------------------------------------
> // WinMain
> //-----------------------------------------------------------------------------
> int
> WINAPI WinMain(HINSTANCE hinstExe,
>                HINSTANCE,
>                PSTR pszCmdLine,
>                int nCmdShow){
>   // Get the command line stuff
>   int argcW=0;
>   LPWSTR *argvW=0;
>   argvW=CommandLineToArgvW(GetCommandLineW(),&argcW);
>   if(!argvW)
>     return(-1);
>   if(argcW<4){
>     GlobalFree(argvW);
>     return(-1);
>   }
> 
>   // Currently supports only 1 arg
>   char *buff=0;
>   char pid[256];
>   char msg[256];
>   char comp[256];
>   char mspath[MAX_PATH];
>   WideCharToMultiByte(CP_ACP,0,argvW[1],-1,
>                       comp,256,0,0);
>   WideCharToMultiByte(CP_ACP,0,argvW[2],-1,
>                       pid,256,0,0);
>   WideCharToMultiByte(CP_ACP,0,argvW[3],-1,
>                       msg,256,0,0);
>   sprintf(mspath,"\\\\%s\\mailslot\\cramp_mailslot#%s",comp,pid);
> 
>   HANDLE h_file=0;
>   h_file=CreateFile(mspath,
>                     GENERIC_WRITE,
>                     FILE_SHARE_READ,
>                     NULL,
>                     OPEN_EXISTING,
>                     FILE_ATTRIBUTE_NORMAL,
>                     NULL);
>   if(h_file==INVALID_HANDLE_VALUE)
>     return(-1);
> 
>   DWORD cbWritten=0;
>   int ret=0;
>   ret=WriteFile(h_file,msg,strlen(msg)+1,&cbWritten,NULL);
>   CloseHandle(h_file);
>   h_file=0;
> 
>   return(!ret);
> }
> ________________________________________
> Dhruva Krishnamurthy
> Proud FSF member: #1935
> http://schemer.fateback.com/
> 
> 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: GNU Emacs: Client/Server

[Dhruva Krishnamurthy]

On 30 Jan 2004 11:38:14 +0100, "Kim F. Storm" <storm@cua.dk> said:
> > 
> > PS: I am not sending this mail to the list, not to annoy people who are
> > not interested.
> 
> I don't have all the answers (and questions) on this subject, so it
> is ok to CC: emacs-devel.

 Not a problem.

> The problem with your code is how to mix it with code that must ALSO wait
> on normal network receive and process output.  In your code, you have
> two waiting-points (as I understand it:)
> 
> >     fResult=GetMailslotInfo(g_CRAMP_Profiler.g_h_mailslot,
> 
> which I assume waits for connections, and
> 
> >       fResult=ReadFile(g_CRAMP_Profiler.g_h_mailslot,
> 
> which I assume waits to receive data.

Yes.

> Both of these must --somehow-- be wrapped in such a way that they
> become non-blocking operations and/or will function through the normal

This code will be running in it's own thread. So, the main thread is not
blocked (am I missing something?).

> "select" call which more or less combines all waiting points for async
> processing in emacs into one.  Actually, I'm not sure select is
> "normal" on W32, but that's the interface you need to emulate to add
> mail-slot support to emacs'.

No idea about that. Never used "select" (used it in PERL).

However, I just recalled that MAIL SLOTS in W32 uses UDP internally. So,
I am fairly certain now that we can get this working using
"make-network-process" in ELisp. I just wrote a very simple ELisp code
(has to be simple if I could write it!) to start a server and listen on a
port. Another method which establishes a connection if server is running
and sends expressions to be evaluated by the server. My gut feeling is
that we can easily have a Elisp implementation of basic "gnuserv"
functionality atleast to open files on existing GNU Emacs process.

Please corect me if I am wrong in my understanding or gross oversights.

with warm regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: GNU Emacs: Client/Server

[Kim F. Storm]

"Dhruva Krishnamurthy" <devel@member.fsf.org> writes:

> > Both of these must --somehow-- be wrapped in such a way that they
> > become non-blocking operations and/or will function through the normal
> 
> This code will be running in it's own thread. So, the main thread is not
> blocked (am I missing something?).

(Yes) -- in emacs, network processes do not run in a separate thread.

> However, I just recalled that MAIL SLOTS in W32 uses UDP internally. So,
> I am fairly certain now that we can get this working using
> "make-network-process" in ELisp. I just wrote a very simple ELisp code
> (has to be simple if I could write it!) to start a server and listen on a
> port. Another method which establishes a connection if server is running
> and sends expressions to be evaluated by the server. My gut feeling is
> that we can easily have a Elisp implementation of basic "gnuserv"
> functionality atleast to open files on existing GNU Emacs process.

Stefan has already rewritten start-server to use an internal server
process rather than the external emacsserver program.  It listens on a
local (unix) socket for emacsclients to connect.

As Stefan has pointed out, using TCP (or UDP) would be a generally
useful solution on other platforms.

There are some security issues here, but maybe it would be sufficient
to restrict such use to local emacsclients, e.g. by binding the 
server to the local-interface, i.e. 127.0.0.1:<EMACSPORT>.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: GNU Emacs: Client/Server

[Richard Stallman]

if "mail slots" are a Windows-only feature, I would rather we not put
anything beyond trivial code into Emacs to support them.  It would
be a distraction from our mission.  Our aim is to replace proprietary
software, not enhance it.

Re: GNU Emacs: Client/Server

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> if "mail slots" are a Windows-only feature, 

I think they are.

>                                             I would rather we not put
> anything beyond trivial code into Emacs to support them.  It would
> be a distraction from our mission.  Our aim is to replace proprietary
> software, not enhance it.

It seems that we can achieve the same goals with the existing features
(e.g. UDP or TCP sockets), so I don't see a need to add mail slots.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: GNU Emacs: Client/Server

[Dhruva Krishnamurthy]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

Hello,
 Based on the suggestion I had on implementing a emacs client/server in
 pure Elisp, I have come up with a working _Prototype_. The code needs
 lot of cleanup and I am sure can be improved a lot. This is my first
 shot at Elisp programming, I request you to kindly help.

Some of the features:
- Server is bound to localhost by default (for security issues) but can
be changed
- Server accepts a *secret* word which is then used to validate all
client connections
  Ex: (emacsserver-start "secret")
- Multiple servers supported in a single invocation of emacs (per
session) but on 
  different ports.

- Client opens a connection on a running server with no authentication
(may be a 
  security risk)
- To execute any expression on the server, the connection must be
authenticated. Hence,
  internally, the first expr sent to server is the *secret* word as an
  argument to the
  client command dispatching function.
  Ex: (emacsserver-client '(find-file \"~/_emacs\") "secret")
- The secret word is store in a hash in the server for the client
process. With this,
  you can send multiple commands (some work needs to be done here)

I am sending the Elisp file which is 7Kb. I request help and guidance to
make this robust and acceptable. My apologies in advance for those who
are not interested.

with regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

[-- Attachment #2: emacsserver.el --]
[-- Type: application/unknown, Size: 6878 bytes --]

[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: GNU Emacs: Client/Server

[Stefan Monnier]

>  Based on the suggestion I had on implementing a emacs client/server in
>  pure Elisp, I have come up with a working _Prototype_. The code needs
>  lot of cleanup and I am sure can be improved a lot. This is my first
>  shot at Elisp programming, I request you to kindly help.

Maybe you know it and you're just experimenting, but I just want to make
sure you do realize that gnuclient/gnuserver already solve those problems,
so clearly there isn't much point is creating yet another system.  What we
want instead is to extend server.el and emacsclient.c with support for TCP
sockets (and maybe add an elisp version of emacsclient.c).

> - Server accepts a *secret* word which is then used to validate all
> client connections
>   Ex: (emacsserver-start "secret")

I'd prefer an automatically generated random string, but it otherwise
looks reasonable.


        Stefan

Re: GNU Emacs: Client/Server

[Dhruva Krishnamurthy]

On 05 Feb 2004 10:05:01 -0500, "Stefan Monnier"
<monnier@iro.umontreal.ca> said:
> Maybe you know it and you're just experimenting, but I just want to make
> sure you do realize that gnuclient/gnuserver already solve those
> problems, so clearly there isn't much point is creating yet another system.

What about portability and distribution issues since it is written in C?
My idea was to write the whole stuff in Elisp and allow Emacs to handle
the platform dependend stuff.
with this approach, I can be sure that where Emacs runs, the
client/server code will run 
with no extra effort.

> What we want instead is to extend server.el and emacsclient.c with support
> for TCP sockets (and maybe add an elisp version of emacsclient.c).

This is not a problem. I had a brief look at the _usage_ of emacsclient.c
source (since
I cannot build it on w2k). IMHO, you can just visit files (at line and
col) using the
client and nothing beyond like invoking commands etc. Please correct me
if I am wrong in
my assumption. I plan to go ahead with a Elisp version of emacsclient.c
shortly.

> > - Server accepts a *secret* word which is then used to validate all
> > client connections
> >   Ex: (emacsserver-start "secret")
> 
> I'd prefer an automatically generated random string, but it otherwise
> looks reasonable.

How will the client know the randomly generated string to establish an
auth'ed connection? Do you suggest that the random string be stored in a
file which only the user invoking the server has access?

-dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: GNU Emacs: Client/Server

[David Kastrup]

"Dhruva Krishnamurthy" <devel@member.fsf.org> writes:

> On 05 Feb 2004 10:05:01 -0500, "Stefan Monnier"
> <monnier@iro.umontreal.ca> said:
> > Maybe you know it and you're just experimenting, but I just want to make
> > sure you do realize that gnuclient/gnuserver already solve those
> > problems, so clearly there isn't much point is creating yet another system.
> 
> What about portability and distribution issues since it is written in C?

What about it?

> My idea was to write the whole stuff in Elisp and allow Emacs to
> handle the platform dependend stuff.  with this approach, I can be
> sure that where Emacs runs, the client/server code will run with no
> extra effort.

I'd be surprised if you manage to compile Emacs without a C compiler
on any platform.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: GNU Emacs: Client/Server

[Dhruva Krishnamurthy]

On 06 Feb 2004 10:52:17 +0100, "David Kastrup" <dak@gnu.org> said:
> "Dhruva Krishnamurthy" <devel@member.fsf.org> writes:
> 
> > On 05 Feb 2004 10:05:01 -0500, "Stefan Monnier"
> > <monnier@iro.umontreal.ca> said:
> > > Maybe you know it and you're just experimenting, but I just want to make
> > > sure you do realize that gnuclient/gnuserver already solve those
> > > problems, so clearly there isn't much point is creating yet another system.
> > 
> > What about portability and distribution issues since it is written in C?
> 
> What about it?

Sorry for not being clear. I meant using platform dependend stuff like
sockets and other headers which are not available on windoze platform in
the same way as it is on Unix.

> > My idea was to write the whole stuff in Elisp and allow Emacs to
> > handle the platform dependend stuff.  with this approach, I can be
> > sure that where Emacs runs, the client/server code will run with no
> > extra effort.
> 
> I'd be surprised if you manage to compile Emacs without a C compiler
> on any platform.

In the above statement, I meant the porting issue (in writing it in
Elisp) and not the compilation part of GNU Emacs. I would like to know if
there is anyone who has succeeded in building all the sources in
"lib-src" folder and user "server.el" on a windoze platform (not using
the cygwin layer).

-dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: GNU Emacs: Client/Server

[Stefan Monnier]

>> Maybe you know it and you're just experimenting, but I just want to make
>> sure you do realize that gnuclient/gnuserver already solve those
>> problems, so clearly there isn't much point is creating yet another system.
> What about portability and distribution issues since it is written in C?

First, my point was at least as much about "change server.el rather than
creating a new emasserver.el" than about "modify emacsclient.c instead
of creating a new emacsclient.el".
One of the reasons for emacsclient.c is that it should be faster
to execute.  Now this is not necessarily the case and for other reasons
I think it might be worthwhile to implement an elisp version of the
emacsclient.
As far as portability is concerned, it shouldn't be that bad since it's just
some TCP socket code in emacsclient.c which AFAIK will only require some
header-inclusion-tweaking to get working: the code in itself will hopefully
work in both Unix and w32 environments without too much trouble.

>> I'd prefer an automatically generated random string, but it otherwise
>> looks reasonable.

> How will the client know the randomly generated string to establish an
> auth'ed connection? Do you suggest that the random string be stored in a
> file which only the user invoking the server has access?

Yes.  Much like Xauth (which gnuserv uses).


        Stefan

Re: GNU Emacs: Client/Server

[Richard Stallman]

It makes no sense to write emacsclient in Lisp, because then
you would have to start Emacs to run it.  Starting Emacs takes
a long time.  emacsclient is a very small program and does
its whole job much faster than an Emacs could start.

Re: GNU Emacs: Client/Server

[Kim F. Storm]

"Dhruva Krishnamurthy" <gnu@furby.fastmail.fm> writes:

> Hello,
>  The fact that "emacsclient" does not build on MS Windows platform
>  (correct me if I am wrong), we end up depending on "gnuserv"
>  functionality. This is *NOT* part of distribution and therefore makes it
>  difficult to keep update with changes in "gnuserv" (if there are any,
>  recently).
> 
>  I was toying with the idea of making the GNU Emacs behave as a client or
>  server through command line options or Elisp functions.
> 
> (On Microsoft Platform on which I work)
> For server:
> - Create a server thread which will use some IPC (mail slots or named
> pipes kernel object) through which Elist expressions can be exchanged
> which can be evaluated by the server

If we could enhance make-network-process to support either of these
connection types (both as client and server), I don't see why not.

I guess it would be a different :family, e.g. :family mailslot, with
suitable new ADDRESS format for :local and :remote addresses, and then
extend the process code to handle such connections/servers as any other
kind of service.

I don't know what it takes to handle connection setup, input/output,
etc., so I cannot say whether it can be done through the normal process-

If you have specific ideas how to do this, you are welcome to discuss
them here.


Alternatively, can't you just use an oridinary stream socket on some
random port of your choice?


> Could we use the above approach and do away with the gnuserv/emacsclient
> dependency?

I would suppose that if it is done properly, the emacs server side for
Windows would then be the same as for the currently supported platform
(except for initial setup, of course).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: GNU Emacs: Client/Server

[Dhruva Krishnamurthy]

On 29 Jan 2004 13:41:17 +0100, "Kim F. Storm" <storm@cua.dk> said:
> If we could enhance make-network-process to support either of these
> connection types (both as client and server), I don't see why not.
> 
> I guess it would be a different :family, e.g. :family mailslot, with
> suitable new ADDRESS format for :local and :remote addresses, and then
> extend the process code to handle such connections/servers as any other
> kind of service.
> 
> I don't know what it takes to handle connection setup, input/output,
> etc., so I cannot say whether it can be done through the normal process-
> 

I suggested Mail Slots as I had worked on implementing it in one of my
projects (controlling a profiling session on a remote computer). It was
very easy to implement it and hence suggested as a way to achieve IPC.
Also, there is not much difference between Mail slot communication on
local computer or remote computer (it is abstracted). Anyway, my views
are based on development on MS Win32.

with regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: GNU Emacs: Client/Server

[Roman Belenov]

"Dhruva Krishnamurthy" <devel@furby.fastmail.fm> writes:

> I suggested Mail Slots as I had worked on implementing it in one of my
> projects (controlling a profiling session on a remote computer).

AFAIK they are actually used by gnuserv, so you can reuse the code
(and it seems to me that the whole idea is just an embedding of
gnuserv functionality/codes into Emacs executable).

-- 
 							With regards, Roman.

Re: GNU Emacs: Client/Server

[Dhruva Krishnamurthy]

On Thu, 29 Jan 2004 16:46:46 +0300, "Roman Belenov" <rbelenov@yandex.ru>
said:
> "Dhruva Krishnamurthy" <devel@furby.fastmail.fm> writes:
> 
> > I suggested Mail Slots as I had worked on implementing it in one of my
> > projects (controlling a profiling session on a remote computer).
> 
> AFAIK they are actually used by gnuserv, so you can reuse the code
> (and it seems to me that the whole idea is just an embedding of
> gnuserv functionality/codes into Emacs executable).
> 

If that is the case, that would be ideal. Since gnuserv is well tested,
it should not be too difficult for seasoned GNU Emacs hackers to embed
it. The big advantage of Mail Slots is the ease of implementation
(atleast on MS platform). It is very easy to come up with clients to talk
to GNU Emacs. Also, the embedding can be done through a DLL or SO if you
do not want to bloat the GNU Emacs executable size. Like a load on demand
stuff. Since the Server feature is something which can be isolated, it
might be a nice idea to decouple it from the main GNU Emacs executable.
This was just a thought on packaging.

with regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: GNU Emacs: Client/Server

[Stefan Monnier]

>  The fact that "emacsclient" does not build on MS Windows platform
>  (correct me if I am wrong), we end up depending on "gnuserv"
>  functionality. This is *NOT* part of distribution and therefore makes it
>  difficult to keep update with changes in "gnuserv" (if there are any,
>  recently).

I feel like the best way forward is to support TCP sockets rather than only
unix sockets.  This would be an improvement under Unix and would give us
W32 support "for free".

I opposed such a move in the past based on the fact that it implies
a serious security concern.  Of course, the security issue just means we
have to be super extra careful and do proper authentication.

Recently (while bitching at the stupid imap server that keeps asking for my
password even though I already authenticated myself elsewhere), it occurred
to me that a cheap authentication scheme is to see whether the remote
process has write access to a particular file: i.e. send a random string
to the remote process, and when the remote process replies, check whether
[ `cat ~/.server-check` = "$the-random-string" ].
Of course, the NFS propagation delay may make this unusable, but maybe
if we check [ -d "~/.server-$the-random-string" ] instead, it will work.


        Stefan

Re: GNU Emacs: Client/Server

[Lőrentey Károly]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I feel like the best way forward is to support TCP sockets rather than only
> unix sockets.  This would be an improvement under Unix and would give us
> W32 support "for free".

What improvement would it provide under a GNU or UNIX system?  I think
everything that the TCP server implementation would provide is already
not just possible, but secure and convenient with ssh.

In a multi-user system, it is possible that dozens of Emacs servers
are run simultaneously by different users.  How would emacsclient
decide which network port the user's own instance listens on?  Having
to remember arbitrary network port numbers is IMO not very
user-friendly.  I think

        client$ ssh server emacsclient <args>

is much more convenient than

        client$ emacsclient --host server --port 24352 <args>

Furthermore, the former command already works nicely, and it supports
opening new Emacs frames on the client side---both X and (in my arch
branch) terminal frames.  Implementing something similar in the raw
TCP case would require extensive changes that are IMHO simply not
worth the effort.

UNIX domain sockets are useful and secure; I don't see why they should
be abandoned.

-- 
Károly

Re: GNU Emacs: Client/Server

[Stefan Monnier]

> UNIX domain sockets are useful and secure; I don't see why they should
> be abandoned.

I have no intention to abandon them.
But if people want to add w32 support, they better do it via TCP sockets
(which will then also work under unix and will require much less code
changes) than some supposedly simple w32-only communication system.


        Stefan