I've got two processes running on two different machines that have to
talk to each other. I was thinking of using Corman Lisp on one and
cmucl on the other. Was are good ways of setting up communications
between the two. In particular what particular libraries are there for
this sort of thing.
Please if you haven't actually used the software don't say anything.
( If used only one end then that's OK but only for that end. )
I've had it up to here with "I haven't used this configuration, but it
should work..." and then spending hours trying to get the fscking
thing run and giving up. Either you know it works as a fact or shut
up.
* Thaddeus L Olczyk wrote:
> I've got two processes running on two different machines that have to
> talk to each other. I was thinking of using Corman Lisp on one and
> cmucl on the other. Was are good ways of setting up communications
> between the two. In particular what particular libraries are there for
> this sort of thing.
As I'm sure you know, there are basically only two acceptable ways for
two systems to communicate in the modern day:
1. CORBA;
2. XML & SOAP.
Implementing either of these is simple, because you don't have to.
You simply start reading the specs, and by the time you've understood
them you start reading the new spec since the one you understood is
now obsolete. This is the great joy of web services: they have *zero*
implementation cost, because no implementation is possible. Which is
fine because no one actually wants them. You know this because people
say things like this:
The most important aspect of Web services is that it's a
standards-based, service-oriented architecture thart is supported
by every major software and hardware company in the world.
Funny, I would have expected the *most important* aspect to be
something like `there is this cool thing that everyone wants to do and
which we can make huge money by providing', but they seem to have
missed that bit and cut straight to the slowly being crushed to death
by weight of standards stage. I think this is technically known as
`clutching at straws' or `we invested billions and billions of dollars
in the web, we'd better find *something* useful for it to do, or at
least something that distracts attention from some of the more
embarrassing, not to say illegal, things in our accounts'.
OK, sorry, I've just been reading an article on this stuff in a
quite-reputable magazine (there are many more amusing quotes in it),
so I needed to get that off my chest. The real answer is sockets and
sexprs down the resulting stream, the same as it's always been. Both
Corman CL and CMUCL have this. But do remember to call it an
`XML-based, service-oriented protocol', or you'll never work in this
town again.
--tim
On 29 Jun 2002 23:53:44 +0100, Tim Bradshaw <···@cley.com> wrote:
>The real answer is sockets and
>sexprs down the resulting stream, the same as it's always been. Both
>Corman CL and CMUCL have this.
I'm trying to understand this.
Are you saying that they come with socket libraries?
If not are there any available?
* Thaddeus L Olczyk wrote:
> On 29 Jun 2002 23:53:44 +0100, Tim Bradshaw <···@cley.com> wrote:
> I'm trying to understand this.
> Are you saying that they come with socket libraries?
Yes. I don't have corman lisp to hand, but for CMUCL something like:
(defun get-www-root (host &optional (port 80))
(with-open-stream (s (system:make-fd-stream
(ext:connect-to-inet-socket host port)
:input t :output t))
(format s "~&GET / HTTP/1.0~%~%")
(force-output s)
(loop for line = (read-line s nil nil)
while line
collect line)))
Does what you think. Server side stuff is more fiddly, you have to do
the whole socket/bind/accept ritual.
--tim
Tim Bradshaw <···@cley.com> writes:
> Yes. I don't have corman lisp to hand, but for CMUCL something
> like:
>
> (defun get-www-root (host &optional (port 80))
> (with-open-stream (s (system:make-fd-stream
> (ext:connect-to-inet-socket host port)
> :input t :output t))
> (format s "~&GET / HTTP/1.0~%~%")
> (force-output s)
> (loop for line = (read-line s nil nil)
> while line
> collect line)))
>
> Does what you think.
(Depending on how well your machine and the server agree on what a
newline is, in the context of the HTTP RFC.)
John Wiseman
Thaddeus L Olczyk <······@interaccess.com> writes:
> Are you saying that they come with socket libraries?
I only know the Corman side of the fence. It comes with socket
libraries.
Have a look at modules/sockets.lisp for examples at the end of that
file. Examples are like:
(let ((s (make-client-socket :host "www.double.co.nz" :port 80)))
(with-socket-stream (stream s)
(write-line "GET / HTTP/1.0" stream)
(write-line "" stream)
(force-output stream)
(loop as line = (read-line stream nil :eof)
until (eq line :eof)
do (format t "~A~%" line))))
There is also acl-socket.lisp available from the AllegroServe port at
[1] that puts an ACL like socket layer around the Corman socket layer.
I think sockets are currently your best bet.
[1] http://www.double.co.nz/cl
Chris.
>> Are you saying that they come with socket libraries?
> I only know the Corman side of the fence. It comes with socket
> libraries.
So does CMUCL. In fact, CMUCL also has a data transmission protocol
called WIRE and a remote command protocol called REMOTE (layered on
top of WIRE). It's a fairly straightforward protocol; as one data
point, it takes only an hour or three to make a Perl port. The big
thing it's missing (IMHO) is distributed GC.
Cheers,
joelh
Thaddeus L Olczyk wrote:
>
> On 29 Jun 2002 23:53:44 +0100, Tim Bradshaw <···@cley.com> wrote:
>
> >The real answer is sockets and
> >sexprs down the resulting stream, the same as it's always been. Both
> >Corman CL and CMUCL have this.
> I'm trying to understand this.
> Are you saying that they come with socket libraries?
> If not are there any available?
Check out the port package (particular net.lisp) from clocc. It should give
you a portable socket interface. As far as i know at least CMUCL is supported.
I'm not shure about corman lisp. However, it should not be hard to include
it into the package (and will give you honor & glory, too ;-)
Best
AHz
Andreas Hinze <···@smi.de> wrote in message news:<·················@smi.de>...
> Thaddeus L Olczyk wrote:
> > On 29 Jun 2002 23:53:44 +0100, Tim Bradshaw <···@cley.com> wrote:
> >
> > >The real answer is sockets and
> > >sexprs down the resulting stream, the same as it's always been. Both
> > >Corman CL and CMUCL have this.
> > I'm trying to understand this.
> > Are you saying that they come with socket libraries?
> > If not are there any available?
>
> Check out the port package (particular net.lisp) from clocc. It should give
> you a portable socket interface. As far as i know at least CMUCL is supported.
> I'm not shure about corman lisp. However, it should not be hard to include
> it into the package (and will give you honor & glory, too ;-)
the biggest problem with clocc and corman is defsystem and logical
pathnames, which clash with the corman internal windows style pathname
structure.
I'm trying to clean up things a bit on the corman side to enable
defsystem and the rest, but cormanlisp 2.0 is almost ready.
······@x-ray.at (Reini Urban) writes:
> Andreas Hinze <···@smi.de> wrote in message news:<·················@smi.de>...
> > Thaddeus L Olczyk wrote:
> > > On 29 Jun 2002 23:53:44 +0100, Tim Bradshaw <···@cley.com> wrote:
> > >
> > > >The real answer is sockets and
> > > >sexprs down the resulting stream, the same as it's always been. Both
> > > >Corman CL and CMUCL have this.
> > > I'm trying to understand this.
> > > Are you saying that they come with socket libraries?
> > > If not are there any available?
> >
> > Check out the port package (particular net.lisp) from clocc. It should give
> > you a portable socket interface. As far as i know at least CMUCL is supported.
> > I'm not shure about corman lisp. However, it should not be hard to include
> > it into the package (and will give you honor & glory, too ;-)
>
> the biggest problem with clocc and corman is defsystem and logical
> pathnames, which clash with the corman internal windows style pathname
> structure.
Actually I would rephrase this. The problem is that Corman Lisp is
not yet ANSI conformant enough to support any of the DEFSYSTEMs
around.
> I'm trying to clean up things a bit on the corman side to enable
> defsystem and the rest, but cormanlisp 2.0 is almost ready.
That is good.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
>
> 1. CORBA;
>
> 2. XML & SOAP.
>
> Implementing either of these is simple, because you don't have to.
> You simply start reading the specs, and by the time you've understood
> them you start reading the new spec since the one you understood is
> now obsolete. This is the great joy of web services: they have *zero*
> implementation cost, because no implementation is possible. Which is
> fine because no one actually wants them.
Intensive marketing (it need not even be clever marketing) can easily
manufacture a "want". The trouble is that unless we're very careful in the
coming years we might be complicit in creating an artificial need that
eventually becomes a real one.
> Funny, I would have expected the *most important* aspect to be
> something like `there is this cool thing that everyone wants to do and
> which we can make huge money by providing', but they seem to have
> missed that bit and cut straight to the slowly being crushed to death
> by weight of standards stage.
Long may this slow death continue. The prospect of XML & SOAP becoming most
usable in conjunction with Microsoft's 'Palladium' is not pleasing.
Tim Bradshaw <···@cley.com> writes:
> As I'm sure you know, there are basically only two acceptable ways for
> two systems to communicate in the modern day:
>
> 1. CORBA;
> 2. XML & SOAP.
>
> Implementing either of these is simple, because you don't have to.
> You simply start reading the specs, and by the time you've understood
> them you start reading the new spec since the one you understood is
> now obsolete.
Yow. That was way harsh. True, I guess, to _some_ extent, but still
harsh.
Did you get bitten badly by something recently? I sense a good war
story lurking behind your words.
Personally, I use CORBA pretty regularly, and it seems to do the job.
If the whole world was lisp, then yeah, I guess sockets + sexps, but
it isn't and corba seems to do the job as a lowest common denominator.
ob war story: I just lost big-time recently; I had written, long ago
some IDL like this:
typedef string Token;
because I was pretty sure one day I'd want Token to be more than just a
string. Eventually that day came, and I wanted to replace it with
struct Token {
long oid;
MD5 sum;
};
for reasons I won't go into. Well, one of our processes is written
in Java. Turns out Java doens't _have_ "typedef", so, their mapping
into CORBA? If the typedef is to a "basic" type, just ignore it, and
place string everywhere. There is _no_ Token type left in the Java app.
Thus, if I now make the desired change, that whole code will break.
In lisp, I defined a token= method, of course, so I'd just re-implement
that and Bob'd be my uncle.
I'm not sure where I was going with this, but the conclusion is that
corba _does_ suck and Java probably sucks even more. Oh well.
* Alain Picard wrote:
> Personally, I use CORBA pretty regularly, and it seems to do the job.
> If the whole world was lisp, then yeah, I guess sockets + sexps, but
> it isn't and corba seems to do the job as a lowest common denominator.
Yes, I think I was unfair to CORBA. Given its constraints - that you
can write bindings reasonably easy for FORTRAN and COBOL (particularly
the latter I assume), and given that it is a committee product, then
it's not too bad. It does actually solve a problem that needs solved.
However I think it's important that people who want to use CORBA bear
in mind how big it is: as big as CL, and much worse designed. For
small projects, CORBA is going to dominate the cost of the project
unless you are already familiar with it.
I guess my annoyance at it is partly this, but mostly that one of the
things we have to do is build C++ applications which use CORBA, and
this has really scarred me. 300MB gcc images and compilation times
measured in hours or days are just not funny. At the other end of the
scale, we have a hello world application that is 260 lines of C++ and
IDL which we use for testing and takes 5 minutes to compile. The IDL
compiler we use produces *11* output files for each input file.
Finally, it *really* annoys me when people complain about how CL is
this horrible committee-produced language. Those people either have
an agenda, or they've not looked at the results of very many
committees.
As for XML / SOAP, well. There must be something good about it, I
suppose.
--tim
> As I'm sure you know, there are basically only two acceptable ways for
> two systems to communicate in the modern day:
>
> 1. CORBA;
>
> 2. XML & SOAP.
>
> Implementing either of these is simple, because you don't have to.
> You simply start reading the specs, and by the time you've understood
> them you start reading the new spec since the one you understood is
> now obsolete. This is the great joy of web services: they have *zero*
> implementation cost, because no implementation is possible. Which is
> fine because no one actually wants them. You know this because people
> say things like this:
>
> The most important aspect of Web services is that it's a
> standards-based, service-oriented architecture thart is supported
> by every major software and hardware company in the world.
I think you just described approximately 90% of all articles
in "Communications of the ACM" these days. Alas.
--
Gareth McCaughan ················@pobox.com
.sig under construc