World: r3wp

I know... I meant thanks for setting it up.

Carl did :)

I just added GC notes..

Graham, on IPC, I think Carl has to be involved in the initial spec. 
I've done point-to-point systems, using TCP ports, but that's not 
a general solution. I've done a tuplespace over Rugby, but it required 
polling. I wanted to revisit Uniserve to replace Rugby in that, but 
it fell off my radar.


Ultimately, I think we need a central process--the tuplespace--that 
apps communicate through. To be general, scalable, and lightweight 
while allowing us to build something like GigaSpaces on top of it 
takes more net guru skills and design effort than I have mustered.

This design-with-discussion model we've been doing lately has worked 
pretty well for modules. Perhaps it can work for callbacks and IPC 
as well. All you need is a lead designer (so it isn't design-by-committee) 
and some quality feedback.

hehe ... I just realized that Carl and I are editing the page simultaneously...

Better edit different sections.

I just added quick notes at the end.  Carl is flusing out the callback 
modes...

Oh, your GC thing should consider concurrency as well. GC won't necessarily 
be the only thing going on.

isn't Carl an author of AmigaOS, a message passing based OS? Aren't 
IPC techniques well known and defined concepts nowadays? Maybe we 
should not come-up with something completly new, just choose what 
fits our model. E.g. we have got async devices ... what about having 
IPC/messaging device?

Obviously, we would be best served by Carl as the lead designer on 
IPC and callbacks :)

If we do IPC through the port model (likely) then there will be a 
device as part of that.

cool, design choosen then :-)

I think it was always intended that way.

is choosing callback and IPC method close to get tasking implemented 
too? :-) That would be cool - the core would feel complete that way 
finally ... I mean - for beta status ...

callback not directly, but threading has some design considerations 
wrt callbacks which are probably all bubbling in Carl's mind.

Inter thread and inter application IPC will most likely be built 
using the same design.

Maybe, just maybe, it might be worthwhile adopting an IPC model that 
is used by others .. so that other languages can connect to REbol?

See distributed IPC http://www.linuxjournal.com/article/2417

ok, that one uses System V signals and Windows doesn't expose signals 
( i think )

The other ipc.lib I mentioned above runs on multiple platforms

I think interop is important, but I don't know if there's a clear 
cross-platform choice. I looked at http://www.spread.org/some time 
back, but it doesn't support Windows and is probably best accessed 
as an extension. 


I can pull notes together for discussion, but I don't want to spend 
time on it without knowing that it has some chance of it being helpful 
and making a difference.

And the very first IPC mechanism I would focus on would be STDIO.

IMO IPC shouldn't be a default thing as there are zillions of ways 
how to do it.

There are zillions of ways, and having choices is good, but if we 
have a standard it will be much easier to write tools that can coordinate 
with each other. If we have rebrowser (or, even better, a generic 
plug-in based app framwork that rebrowser is built on :-), it may 
be something that gets built anyway.

Out of the zillions of options, and with Carl's background and knowledge, 
what is the best option for REBOL (or maybe the top 3)? If Carl has 
ideas/opinions/designs already, could he write up a paragraph that 
outlines how *he* thinks it should be done?

The thing is, that Rebol needs to connect to the rest of the world. 
Rebol-2-Rebol is nice but IMO not the focus at the moment. RebService 
can be picked up again by the community.

Each app choses its own IPC when the OS doesn't have one standard. 
 No single IPC method will be usefull.   


for REBOL itself, I do think that we should provide a construct which 
will be similar or exactly the same as what will be build for thread 
messaging.

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.