[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Sockets, threads and GUI<->Kernel communication
From: |
Gabriel Dos Reis |
Subject: |
Re: [Axiom-developer] Sockets, threads and GUI<->Kernel communication |
Date: |
12 Apr 2007 06:41:28 -0500 |
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
- [Axiom-developer] Sockets, threads and GUI<->Kernel communication, C Y, 2007/04/12
- Re: [Axiom-developer] Sockets, threads and GUI<->Kernel communication,
Gabriel Dos Reis <=
- Re: [Axiom-developer] Sockets, threads and GUI<->Kernel communication, C Y, 2007/04/12
- Re: [Axiom-developer] Sockets, threads and GUI<->Kernel communication, Gabriel Dos Reis, 2007/04/12
- Re: [Axiom-developer] Sockets, threads and GUI<->Kernel communication, C Y, 2007/04/12
- Re: [Axiom-developer] Sockets, threads and GUI<->Kernel communication, Gabriel Dos Reis, 2007/04/12
- Re: [Axiom-developer] Sockets, threads and GUI<->Kernel communication, C Y, 2007/04/12
Re: [Axiom-developer] Sockets, threads and GUI<->Kernel communication, Scott Morrison, 2007/04/13