C Y <[EMAIL PROTECTED]> 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 mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/axiom-developer
