World: r3wp

It is really nice when oportunities rise that way and that someone 
can see potential in small, flexible tools .....

... more on that in my upcoming probably two or threee docs coming 
during weekend ...

RFC: http://www.colellachiara.com/soft/Libs/messaging.r(while we 
wait for RS)

and BTW, maye IN-INTERVAL? can be useful to anyone else too? checks 
if a value is inside an interval, assuming a ring. can be easily 
used for rings mod 2^n where n is multiple of 8, just using binaries. 
see http://www.colellachiara.com/soft/Libs/chord.r

maye = maybe

how can we compare to Rugby, Uniserve - in principle?

that is very short, maybe < 2 pages...it that the whole cannoli?

Petr: wrt to Rugby, it is somewhat similar, but message-oriented 
instead of RPC oriented

Rugby is more advanced, but in principle Rugby is a subset of this 
one.

Steve: that's all, even though it depends on a couple minor things.

message or rpc, it just sounds the same to me?

RPC means that you call a function on the other side, and you get 
back a result

messaging means that you send a value to the other side, and you 
get (possibly) a value in return

or you don't, if you call it in async mode ... but maybe Maarten 
already implemented more than only RPC then ...

messaging does not imply a procedure call, even though in practice 
you will be doing that

if you want to test it, do timers.r and async-protocol.r first (from 
async-protocol it only needs the wait-start and wait-stop functions, 
but you will probably need the async-protocol anyway so...)

well, I seem to understand ...

http://www.colellachiara.com/soft/Libs/timers.r

hmm, what about complete package?

http://www.colellachiara.com/soft/Libs/async-protocol.r

Petr: probably soon.

where's chord? :-) I can see only a parser, that is surely not everything 
Chord related? Is Chord needed for messages.r to work?

and, I tend to always depend on utility.r so you might need it too 
(same location)

http://www.colellachiara.com/soft/Libs/utility.r

chord: will be there tomorrow or so.

i have a prototype that can be easily translated to real code using 
messaging.r and the in-interval? function you see there.

so i just need to change the prototype code into real working code... 
and then test it a bit.

Chord needs messaging.r, not viceversa.

What will we be able to do using Chord? I heard Chord is not about 
P2P (sharing), but some look-up mechanism. Any examples how all that 
stuff could be used within some kind of interesting project/product?

any P2P network needs routing as its basis, doesn't it? Chord provides 
that by providing distributed lookup.

that is, if Gabriele wants to send a message to Petr, he has to know 
where Petr is. In some P2P networks this is handled by sending a 
message to someone esle and route it up to Petr.

with Chord, you directly look up where Petr is and then send a message 
to him directly.

I guess this is the easiest explanation I can give of it :-)

Hmm, interesting. Could be used for look-up of Rebservices later 
:-)

I just wanted to have better idea of how all that stuff compares 
... protocols

exactly. it is very good for implementing DHTs (Distributed Hash 
Tables)

(schemes), Rugby, Rebservices, Uniserve ....

messaging.r is what I need until RS are out :)

I can see Uniserve a multiplexing engine, multiprotocol ... while 
Rebservices could be sent via e.g. IRC procol, whatever - it will 
probably be independent (to some extent) of transport mechanism?

AFAIK it will.

hmm, and if RS will not provide any such advanced look-up mechanism? 
(as I expect it to not)

mine is not, because that is too much effort. (but it is partially)

Chord can be implemented over RS instead of over messaging.r

Chord could be just implemented over UDP too etc., or over Rugby 
and so on

From what I read so far, it seems to me RS are similar to WS, - exposed 
functionality, and you don't do any look-up, you have to know where 
is catalog providing you with description of service and its location 
...

Indeed, that's why I think we need a DHT instead of a catalog service 
for RS

ah, ok, so Chord is independent of messaging.r, messaging.r being 
just temporal solution till RS appear ...

a catalog service is a single point of failure.

exactly...

maybe we could use both of worlds? But then - I can see it with most 
P2P networks - once someone decides to shut-down central site, whole 
system collapses ...