Re: [Axiom-developer] Sockets, threads and GUI<->Kernel communication

[Gabriel Dos Reis]

C Y <address@hidden> writes:

| I looked around and asked on #lisp (thank y'all on #lisp for correcting
| my ignorance about such basic matters).  The upshot appears to be that
| sockets are sufficiently useful to be worth dealing with the firewall
| issues.  This page was mentioned as a useful introduction to the
| options available: 
| http://en.wikipedia.org/wiki/Inter-process_communication  A couple of
| the general protocols have lisp implementations (CORBA: 
| http://clorb.sourceforge.net/ and XML-RPC: 
| http://common-lisp.net/project/s-xml-rpc/) but as far as I can tell
| both involve MORE overhead than sockets, not less.  A real local
| alternative to sockets for inter-process communication would probably
| need to involve pipes or file operations, either one of which I would
| worry about for portability.  I would disagree with the
| characterization of socket use in Axiom as over-engineering - I think
| the client-server setup adds useful flexibility, and sockets appear to
| be the Right Way to implement it.
| 
| I do agree that threads are a more attractive way to implement the
| client-server setup when dealing with a strictly local copy of Axiom,

If you agree with that, then you must agree with the over-engineering
characterization.  We have more uses of Axiom as local copy than we
have as a truly distributed system over network.  A 101 principle
of engineering is to keep common thing simple.

Oh yes, I know Axiom was designed a long time ago; that does not
change my point.

[...]

| Allow Axiom to have both local and remote interface clients. 

Well obviously, no improvement will remove the socket support.
The point wasn't that socket are useless -- quite the contrary.  But,
the engineering has forgotten the basics.

| The
| default would be a local client, with remote connections being handled
| as options.  The flow would be something like this:
| 
| 1)  User starts Axiom client, default settings.
| 2)  Client checks for thread support.
|     a.  If available, start new thread with kernel
|     b.  If not available, start new process with kernel on default
| socket.
| 3)  If process is available in in-image thread, use local calls for IO.
|  If not, send them over the socket.  This should be abstracted and be
| simply a matter of defining a few settings/variables.
| 
| To handle the issue of firewall interaction, I would suggest
| investigating if the NSIS installer can prompt the user to add the
| Axiom client and server programs to the Windows Firewall allowed list,
| and perhaps open the needed port as well.  I'm not sure if this
| functionality is defined there currently but it might be worth
| suggesting, as I doubt Axiom and Maxima would be the only open source
| programs to confront this issue.  It would also be a good idea to make
| sure our error messages are informative in the case of failure to
| connect, and provide all available information for resolving the
| issues.

I'm not a windows developer, so patches are welcome.

-- Gaby