World: r3wp

Interestingly the first site I went to using this software does not 
display this text!  http://code.google.com/p/spread-excel/

Brian, I do commercial app development in REBOL as well as in-house.


Petr, I'm not here to defend Spread. I mentioned it because when 
I looked at it before, it was something I marked to remember because 
it wasn't too large or complex and didn't try to do too much (compared 
to, say, AMQP). 

I only played with it breifly, I didn't put it into production. 

I want a REBOL solution too. :-)

The questions are:

1) What do we need?

2) Can we build it?

Did you get it working at all?

I havne't tried using it from REBOL. Their test apps did work IIRC.

I have worked in enterprise sphere for 35 years and never heard of 
something like "REBOL" from anybody that I've every worked with.


Let's make sure that we don't change this and keep REBOL clean and 
mean and to itself.

Well, for 25 of those years REBOL didn't exist !

2010 - 1997 = 10 ?

rounded down

Mathematics aside, it should be obvious by now that REBOL is not 
in any way attractive in mainstream IT. I believe it's insularity 
doesn't help though that is only one reason. I made the comment tongue-in-cheek 
as I see no relevance to the worthiness or otherwise of a library 
just because somebody who has worked for 15 years in "enterprise 
sphere" never having heard of it.

Whether Spread would be right for REBOL is another matter though 
it would offer a limited  alternative for secure inter-process communications 
with non-REBOL processes without having to resort to either cgi or 
"roll-your-own".

The point is, any software should be judged on its intrinsic merits 
rather than how widly it is used?

Yes. For many, merits include robustness, reliability, documentation, 
support and availability of skilled people.

..and of course, its ability to integrate with what they already 
have.

Maybe we should make a list of candidate libraries and decide what 
is the best fit to our as yet unstated needs?

Perhaps it would be even better to state our needs for inter-process 
communication first?

Well I first raised the quesion of how an external extension might 
be able to communicate with the rebol application

PeterWoo - you talk nonsense, which belongs in advocacy group :-) 
If you work for 35 years in enterprise, then tell me, if you met 
spread there. The messaging is done by so called middlewares. IBM 
has MQ series, SAP has XI. Those engines use the so called connectors. 
Everybody went the web-services route, hence having ability to talk 
SOAP might be more important for REBOL. I never argued against having 
as much libraries as possible wrapped to REBOL, the only thing I 
argued against is eventual 200KB library inclusion in REBOL, just 
to do IPC between REBOL tasks ...

but hopefully not arrogant nonsense :-)

Well - I don't mind. It is not about if I ever heard about it. It 
is all about - how much interoperability with outer world do we get? 
E.g. - can you talk to most Windows or Linux (Unix) apps with it, 
like Amiga Arexx? Can you talk to SAP, Orcle APPs, WebSphere, SharePoint, 
etc. enterprise apps? In fact and once again - -I expect having extensions 
to as many systems as possible, but we surely also know, how picky 
is Carl about what is going to be included into standard distro, 
and 50KB is considered being a big addition :-)

Spread requires a daemon to be running ... so this doesn't fit

what I would like to see for IPC mechanism is some port/events mechanism. 
And then, on top of that, the way to go is the Uniserve like engine. 
Python has Medusa - simply put - multiprotocol engine, to communicate 
with external world ...

Graham IMO almost every IPC need somewhat daemon runing. The library 
"could" be linked in extension and try to open communication with 
daemon, when it doesnt find the daemon let start its own (first process 
trying to comunicate), what is nice in Spread it combines P2P and 
multicast and members/group policy, and of course single/multi machines.

Pekr I think in port event model the only what is neccessary is open 
events to OS events (what possibly is already done, but we don't 
know how to use it), not only GUI events. Than you can use local 
pipes (managed by OS including event signalling). Question is if 
multi machines IPC would go this way. Anyway all this is solved in 
QNX (signalling abstraction local/external). Question if they use 
sockets for this.

Pavel - yes, we have so called system port, but we don't know much 
about it :-) I hope we get Amiga/QNX kind of design in the end. At 
least that is what I would expect from the messaging expert, Carl 
:-)

Petr, Peter doesn't talk nonsense IMO. There are a lot of things 
REBOL could use for interop. SOAP would be a protocol, not an extension. 
REBOL IPC may be a protocol too. MQ et al would be for specific systems, 
not general IPC. I'm all for a Uniserve model.


Historically, memory mapped files were one of the most efficient 
IPC mechanisms on Windows, but if a more portable approach can be 
written based on named pipes, I can live with that. Sockets are great 
as long as you don't run into firewall issues (even locally), and 
might encourage us to think in terms of protocols and messages.


As Pavel said, and one of the main design points, is the need for 
a daemon. Obviously memory mapped files aren't going to work across 
the net.

Pavel, I pulled out my old QNX manual and it lists Messages, Ports, 
and Exeptions as their three IPC mechanisms. Messages can be sent 
on "virtual circuits" which have a node ID in addition to the task 
ID to send to; no implementation details given. Ports were like named 
pipes it seems, with 16 being numbered and reserved by the OS.

Gregg thx for info

Do you really need a daemon if you're just doing IPC on the one PC?

http://www.rebol.net/r3blogs/0328.html


Missed this one ...  "So, what I need to know from you is what functions 
published in the r3lib API should also be provided in the extension 
API. No, you cannot have them all, because many are only relevant 
to the host bootstrap itself."

Graham, you don't for a single machine, but you would need a memory 
mapped file, named pipe, or something else. The question is whether 
you want an IPC system that is limited to the local machine.

So, there is the possibility then of two ipc mechanisms .. one for 
local ipc, and for one distributed ipc ...

Graham, one advantage of using a daemon approach to inter-process 
communication is that it is very easy to upgrade an application from 
single-user, single-machine to multi-user, multi-machine.

Is Carl prepared to do this though?

http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx

I don't know Carl's thoughts. I also don't know how ARexx ports worked 
on the Amiga. They may have just been named pipes, but I don't think 
that's enough today.

If we want to pursue IPC chat, make suggestions, and get Carl involved 
(at least get some his thoughts), we should do it in a different 
group or somewhere else. Should we do it on AltME or somewhere else?

a good thing is to make a wiki open discussion about it.  collect 
ideas, wants, needs, gotchas, known tools... whatever.  when Carl 
addresses this, he will have a document to review and analyse.

Carl reacts quickly, when he has all the information in front of 
him.

Agreed, with the goal of gathering information, though I'm also a 
bit hesitant as he may have strong feelings and ideas already. 

I'm good with a wiki though. Where?

where all the others are being placed...  somewhere under here... 
http://www.rebol.net/wiki/Main_Page

for example: http://www.rebol.net/wiki/External_Callbacks

Draft IPC wiki page is up: http://www.rebol.net/wiki/IPC_-_Inter-process_communication

wow, looks like the framework for a thesis  ;-)

I have a lot of notes. :-) I tried to keep it minimal, focusing on 
a few key questions to start, with an eye on the bigger things that 
would be built on the foundation.

I added a threading section to the IPC document.

just notes and questions.  IIRC we talked about this at some point.

The most important questions are probably missing: _what_ kind of 
"processes" are we talking about. Is it about communication between 
R3 tasks (within a single process), about multiple R3 processes on 
the same machine, R3 processes across a LAN? WAN? Heterogenous processes?

The daemon question is the primer for both threading and processes. 
The "what are we talking to?" question. I'll add that to the wiki.

I also added a little section on implementation specifics (directly 
in the host, as extension, embedded?, etc)

all the IPC I've done with rebol where TCP socket based, some per 
connection, others with persistent and fault-detection wrappers similar 
to ip packets.