World: r3wp

And you don't need to pass data, they both share the same context 
via the port parameter

Wow, lots of documentation on the wiki. That will be very helpful

There is alot of doc in wiki, but the examples is to be written yet, 
that is why I asked. BTW all the simply schemes at Graham Chiu's 
site  (il dottore :) simply doesn work for me, and yes I've upgraded 
make-scheme to sys/make-scheme for A110. Unfortunately the only scheme 
I know working is the http scheme, but it is too high class to I 
can understand the process.

daytime doesn't work??

I've tryed to make time scheme from your daytime scheme Graham, as 
I noted when I put print at awake level as You did for debug probably 
I can see the server response, but I'm not able to get response at 
the 
read time://server.site
== somenumber

There is missing the "; make something synchronous here" part :-)

I think Christian Ensel's ODBC scheme is the other current example

Interresting, when I write to global variable at awake level everything 
works OK. Somebody give me a hint how to send received data from 
awake to actor level please.

An awake functions deals with events.
An event has a port  property.
An actor takes a port as input parameter.
Here the link.

If the port contains locals vars, they can both (the awake and the 
actor) access the port's locals.

And from subport (tcp) to scheme level port? Can low level awake 
write directly to scheme locals?

Sure, they both share a cross reference in their locals, like in 
R2.

Finally I've got it, so now I have a time scheme returning (RFC 868) 
integer number of seconds from 1-Jan-1900. I tried to define refinement 
/date to return well formated date!. But there is no possibility 
to define different refinement except of hadcoded one so I have to 
use /lines for that, silly.

Would you mind to show the interface/api or the actual implementation 
of your time scheme? You're probably (mis-)using the /LINES refinement 
of READ, but maybe you can instead use WRITE for that ...

ChristianE the idea arises from the fact the time server send only 
response and close immediately, so I only implemented Read actor. 
The problem is that you may not create a new refinement but only 
redefine one existing. 

time scheme needs a little polishing and will be posted to script 
library.

Anyway you are right the only possibility how to controll the scheme 
in wider borders is to write a command block and wait for reply. 
Another not so generall would be write into port state context and 
use this as switch for read actor.

prot-time.r was uploaded to rebol.org, now works only synchronous 
way ie: read time://your.time.server, server must be RFC 868 (port 
37).  basically it returns number of UTC seconds from 1-Jan-1900/0:00:00. 
When refinement /lines it returns well formated local time (using 
local timezone)

Graham, 1. where you put the R3 schemes (if so)? wik.is is definitely 
down. 2. I have to say your daytime scheme doesn't work for me (functionality 
commented out I think). 3. you can add prot-time into your collection 
if you like to.

Pavel, I would not be surprised.   I have not looked at this stuff 
for over a year.   Yes, wik.is is now defunct and so my site is gone.
See https://github.com/gchiu/Rebol3/tree/master/protocols

I'll look at the schemes again when R3 goes beta.

Ah, and R3 goes beta when it has enough schemes...

R3 may go beta before any additional schemes are added - "enough" 
is a matter of opinion, and for core functionality, HTTP is enough 
(only needed for CHAT and UPGRADE). HTTP should be improved before 
beta though.

Sorry, TCP, DNS, probably UDP, and files/directories are also needed 
for beta.

If you need additional schemes for your own projects, contributions 
are welcome.

Nevermind, I was just being sarcastic :-)

As far as I'm concerned, Core should be stamped 3.0 Release after 
another run through the bug list. It's basically only View that is 
not presentable yet

My current gripes are mostly with the documentation

We have been doing beta triage on the bug list already :)

Cool!

Hope I'm not adding new ones too fast ;-)

Kaj - you misunderstood. What BrianH imo means is just general note, 
not any recent activity :-) Last R3 activity of Carl is almost 3 
months old imo ...

You should not forget, that we plan to come into beta for almost 
2 years :-)

I know, but the bug database is being worked on right now

is it?

No, it isn't - we just add new tickets imo. Changelog does not show 
any changes, nor Carl's notes, etc.

Brian is working on it, and if he says Carl is working towards a 
beta, I believe him

I also believe it because, when I first ported my CMS to R3 almost 
two years ago, it didn't fully work, so I decided not to use it; 
and now that I have ported it again I expected the same, but it has 
turned out that I'm using the R3 version now

Further, I can see that most of the important restructurings have 
been done last year, and the source publication has been sorted out, 
so I am now able to fill in missing pieces with extensions, with 
a reasonable certainty that the interface is stable

That is understandable, but it does not contradict my claim, that 
"being doing beta triage" is an still ongoing process, not something 
entirely new :-)

In other words, Core is usable, extensible and published now (since 
a few months)

Yeah, maybe Carl should put a beta moniker on it ASAP.

That's what I suggested

we can be in beta another xy months, then do few RCs, and then 3.0.

when I try to evt: make event! [type: 'custom code: 1] I got: 
== make event! [
    type: 'custom
    offset: 1x0
]

ie code dissappears and the value is merged into offset curiously 
is it intended?

I am not sure making custom events is supported?

minimally it is included in "official" http scheme

ah ... well then ... maybe Cyphre know more about custom events ...

you can create objects instead of event

is it possible to slip object instead of event! ?

slip ?

Event handlers are basically functions, they can accept event! or 
object if they have the same properties.

I am wondering how one would implement the IMAP4 IDLE command .. 
see http://tools.ietf.org/html/rfc2177


It seems that once one sends an IDLE command, the server might then 
send a response back any time up to the server's inactivity timeout.