World: r3wp

Robert, as I said, the first IPC mechanism should be STDIO. :-)

Gregg windows is supported by Spread by default (more exactly Win32)

Good to know Pavel. Thanks.

Gregg... you're suggesting stdio pipes, right?  I'm not sure of the 
quality of their support over all platforms, but perhaps it's possible. 
 Of course, there are no easy alternatives.  IOS had IPC, and it 
was implemented differently for each OS model.  I was going to reuse 
most of that code for R3.  But, it does use sockets for posix, but 
I think they work well.

BTW, I'm not opposed to using something like Spread... does anyone 
know its general size (e.g. complexity level?)


Also, if we went that direction, wouldn't we also want to look at 
MQ in general?

I think that we can have those as external alternatives, but I am 
with Max here - we want the REBOL way ...

+ lots of points for having a code base that's already done and tested!

But is it tested for the same kind of work we are trying to do? No 
points for trying to massage an off-topic codebase into something 
useful.

What is the REBOL way?

Is something that only provides interoperability between REBOL processes?

There would surely be some advantage in be able to send inter-process 
message to non-REBOL applications?

... and to receive them of course.

Carl, by STDIO, I just mean the basics for writing pipe-and-filter 
apps. e.g. 

  while [data: input] [print data]


I just found http://www.rebol.net/cgi-bin/r3blog.r?view=0282so maybe 
we're close and just need to write up some examples and a doc page 
explaining limitations on different OSs. Gabriele has some things 
in his power-mezz package as well (chain, filter, pipe), which are 
worth keeping in mind. The blurring of lines between in-process and 
inter-process, and piping is where we need design direction from 
above. 


A REBOL way (passing around blocks of dialected data, i.e., messages) 
vital, but we also need gateways to other mechanisms. The REBOL way 
is critical because it reduces or eimilates external dependencies 
and provides a model for gatewys to emulate.

It looks like the Win32 binary is from 2006 and the main daemon is 
~200K.

http://www.spread.org/download.html

License note:


This software is licensed under the Spread Open Source License. This 
license is SIMILAR BUT NOT IDENTICAL to the BSD license. Specifically, 
the license includes the requirement that all advertising materials 
(including web pages) mentioning software that uses Spread display 
a specific acknowledgement.

So it's like the old BSD with the advertising clause, the one that 
people complained about. Nifty.

Yeah, but if that's the biggest complaint we have... ;-)

That's not insignificant, as the advertising clause of the old BSD 
made it legally incompatible with a lot of other licenses. Particularly 
(L)GPL, but we as a community need to be avoiding (L)GPL code anyways 
for a lot of reasons. We'll have to be careful.

If it's done as an extension it shouldn't be an issue for RT, correct?

If it's rolled into a host, then you need to care. Having it built 
in would be very cool so, yeah, you're right that we need to care.

One: yes, it would still be a problem even as an external extension. 
Two: we would have to do it as a host-embedded extension if we want 
to use this for the core intertask messaging solution, and that is 
the same as linking the code in.

Remember that advertising clauses are transitive, so all of our apps 
that we build with R3 would need to advertise Spread too. Even apps 
that we build for third-parties.

Yes, if it's built in, we're in sync. But if it's an external extension, 
doesn't it become a problem for us as individuals rather than RT?

Nope, because it becomes a problem for any person who uses that extension 
in their product.

It doesn't matter anyways, because we are discussing the standard 
intertask messaging mechanism for R3. That can't be external, it 
would have to run when external extensions are prohibited by security 
restrictions.

This is why BSD got rid of the advertising clause in the first place.

Yes, that's what I mean. We who distribute it, and passed along to 
those who use our work.

I'm willing to pay that price, but I can only speak for me. :-)

First, though, maybe some design thoughts about what our ideal IPC 
interface would look like.

To be fair, when last I tracked your job situation it didn't involve 
distributing REBOL software to customers directly, so that clause 
probably *would* work for you :)

Yes, design thoughts, back to the subject :)

Gregg - to be honest - 200KB? Total bloat. I work in enterprise sphere 
for 15 years, and never heard of something like "spread". In fact 
- noone in enterprise sphere cares. Guys, really - let's have clean 
 and mean REBOL solution, the REBOL way. Then we can interop with 
other systems, as the need arises. Let's not adhere to pseudo standards, 
because they have some juicy website ...

Re: Spread, it doesn't specifically say how you have to advertise, 
so one small clause on one page somewhere on the website would suffice

But asking each application built with R3 to also include a notice 
like this seems a big pain

I wonder if including this "This product uses software developed 
by Spread Concepts LLC for use in the Spread toolkit. For more information 
about Spread see http://www.spread.org"as a text string in the source 
counts?

Anyway, I guess most apps have some type of licensing that is viewable 
from the app, and you can just include the line in there.

I don't think it's a biggie .. more of an issue is how good is it, 
how complex, has anyone used it etc

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.