[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: 
|  A couple of
| the general protocols have lisp implementations (CORBA: 
| and 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

reply via email to

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