World: r3wp

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.

which would lead to the client timing out on a tcp port

I've been starting to give some thought about how you would make 
an ODBC dialect more powerful by using R3-style scheme tricks. Has 
anyone else come up with some good ideas?

For instance, do we really need to support the manual connection 
pooling that R2 does? By this I mean requiring you to open a database 
port and then doing a FIRST on that port to get the actual connection. 
Shouldn't it be possible to just open a port in one step, and have 
the connection pooling be internal or otherwise hidden?

It did strike me as a kludge

Just came up with a way to maintain R2 compatibility and still support 
the advantages of the R3 style. Just working through the details.

Has anyone made an R3 scheme for testing? I mean a scheme that implements 
every possible port action, but just logs the values passed in. I 
want to get a better idea about how refinements are passed in to 
non-native schemes, if there are any potential security holes, etc.

This would help with people trying to implement the R3 port model 
on any of the REBOL spinoff languages, by comparing the results.

I've done some years ago, let me check :)

Hopefully after /string and such were added to READ :(

my infamous "virtual block" scheme.

https://sites.google.com/site/rebolish/Home/idx.r?attredirects=0&d=1

Don't know if it still works

Infamous indeed :)

Some frenglish comment inside.
Should help

I'm working on an R3-style odbc scheme, but the tricky part is figuring 
out how to make it behave in the best R3 style.

Quick poll: Should READ of an odbc port return flat data, and READ/lines 
return nested blocks? I know it's the opposite of how it was in R2, 
but since we don't have READ/custom we have to make do with what 
we have. For WRITE/lines I've been leaning towards bulk inserts.

see if you can use COPY , COPY/part , COPY/deep as an alternative 
for READ

This scheme is not doing the R2-style two level db, dbconnection 
scheme, it's doing the one-level R3 style with the db connection 
being internal. COPY of a port copies the port itself, returning 
a new connection to the same database. COPY/part returns n new connections. 
The R3 style uses READ and WRITE, not COPY and INSERT.

However, if you do FIRST of an R3-style dbconnection port, I was 
going to return a R2-style dbconnection port, or at least something 
that acts like one (in particular, it will act like ChristianE's 
odbc scheme). You should be able to use R2-style odbc code without 
change.

I don't agree, you can redefine the meaning of any native which supports 
port! as parameter.
See my v-block scheme.
R3 don't constrain the semantic of your scheme

there's no r3-style scheme IMHO

The advantage of this is that you should be able to do really simple 
shortcuts for some operations.

R2-style:
db: open odbc://server
dbc: first db
insert dbc "select * from catalog.schema.object"
copy dbc

R3 style:
read/lines odbc://server/catalog.schema.object

Plus, with R3-style you could write asynchronous stuff that the R2 
style doesn't do.

Your rejection of R3 style is what your block scheme infamous, and 
fun too :)

the asyncrhonous stuff is doable only if one start GUI do-event loop.
Quite limited

Not the GUI event loop, the event loop. Which is as simple as WAIT 
port.

Your block scheme probably wouldn't have benefited from asynchronicity 
that much. Or would it have? That would be interesting to find out.

Async was pretty limited in R2 because you had to start the GUI event 
loop, which only the View builds had. With R3, even core has an event 
loop, and a lot of stuff uses it.

My scheme only open regular files (not a messaging pipe)

It would be interesting to see if there would be a way to make an 
async file scheme using the async or non-blocking file APIs of various 
operating systems. This would be needed to support WinRT-based applications 
for Windows 8, for instance.

I'm sure Linux, Mac and such have non-blocking I/O APIs too.

I think R3 is too slow to benefit of such non blocking API.

It makes sense wh