John Nagle wrote:
> Eric S. Johansson wrote:
>> John Nagle wrote:
>>> Yes. One of the basic design flaws of UNIX was that interprocess
>>> communication was originally almost nonexistent, and it's still not
>>> all that
>>> great. It's easy to run other programs, and easy to send command line
>>> parameters, but all you get back is a status code, plus console-type
>>> output.
>>>
>>> The UNIX world might have been quite different if, when you ran a
>>> subprocess, at the end you got return values for the command line
>>> parameters (argv/argc) and the environment back. Then programs
>>> would behave more like big subroutines.
>> not if you use pickle.
>
> That assumes both programs were designed to intercommunicate that way.
> Most UNIX applications aren't. There's no accepted standard on how
> UNIX programs should intercommunicate, other than the 1970s technology
> of piping human-readable strings around. Yes, there are marshalling
> systems, of which Python's "Pickle" is one. But there's no standard
> interprocess call system. And Pickle is only a marshalling system,
> not a full IPC system. There's no resource location system. ("Where's
> the browser process?" "Where's the database back-end?")
I apologize if this gets you a bit cranky but I think you're conflating a few
interprocess communications issues. I know I didn't fully articulate what I
had
been doing and I apologize.
As your description above shows, there are multiple types of interprocess
communications. My example shows how it's possible to make two cooperatively
designed programs act as if they are communicating via a remote procedure call
across a parent-child process boundary. Yes, other marshaling systems may be
useful across multiple language environments. I wasn't concerned about that.
I
had to get a job done so I used pickle.
when it comes right down to it, IPC systems are hard to do right.
http://birrell.org/andrew/papers/ImplementingRPC.pdf is a pretty good reference
for how to do it for our PCs. Also, the definition of right, depends on the
communications medium used. For example, if the application is using pipes
with
sub processes, what I wrote is a workable implementation especially if you need
to deal with privilege escalation. If you're talking over sockets or some
equivalent communications channel, then yes, you need some form of resource
location as well as handling methods exposure and resolution on both server and
client side. But even if you have all of these items, you're still not out of
the woods. There's a fundamental issue of reliability in the face of this
complexity. I've written some code with psycho and, this is not meant as a
slam
against psycho, but the resource location subsystem was causing more problems
than I care to deal with so I eliminated it from my project by hard coding
certain essential bits of information.
>
> Both Gnome and OpenOffice use CORBA. But they use incompatible versions,
> and you have to have a "CORBA ORB" running for that to work. There's
> OpenRPC, which isn't used much any more. There's "System V IPC", which
> isn't used much. There are XML-based systems. There's REST, JSON, and
> similar approaches. None of these approaches ever got the kind of
> widespread use that OLE did in the Microsoft world.
All of these examples are great examples of overly complex IPC mechanisms.
while the complexity may be necessary if you are going to handle 99% of all
cases, the complexity makes it more difficult to document functionality in a
comprehensible way. complexity reduces take up because it's too much work to
figure out and use especially if it's a one-shot job. I believe it's fairly
clear that a very simple IPC mechanism could handle a significant majority of
project needs while making IPC functionality accessible to more developers.
XML
RPC almost achieves that except for its functional call orientation. But, I'm
not a waste any more breath on "what ifs" because there's way too much
technological alpha male behavior to ever build a simple common infrastructure
component for IPC (or almost any other widely usable components for that
matter).
---eric
--
Speech-recognition in use. It makes mistakes, I correct some.
--
http://mail.python.org/mailman/listinfo/python-list
