World: r3wp

I guess there needs to be a formal limit to what RT does and what 
community should do. It can't be expected that RT would maintain 
console support on an obscure OS. OTOH you might expect HTTP to work 
as a result of RT work or someone close to RT.

Hasn't this been demarcated already?

Don't think there is anything but a task list.

I'm also unclear as to the license behind community contributed stuff. 
 Say Anton spends a couple of weeks doing an ftp scheme ... under 
what license should it be publshed as ?

Henrik - and I say I don't care how it happens. The only important 
thing is - the product and its state. If you have no answer for "who 
does it", RT is still responsible, if they want to market REBOL. 
That is why I thought bounties might help to sponsor some ppl willing 
to bring-in some usefull contributions ...

licensing was not revealed yet ....

Hmm ...

Perhaps everyone should BSD their contributions ...

As soon as people start making them of course ...

this is now declared a GPL free zone ... thanks for cooperating.

I care about how it happens, because process of knowing who does 
what will become increasingly important as R3 grows. Extensions is 
just one area where people freely can contribute under the BSD license. 
If you don't want it public, don't publish.

BSD has the best integration opportunity, yes

Now soon, GUI work will continue and there are graphics subsystem, 
OpenGL, etc. Enough work for 4-5 people there alone.

And one maintainer per OS platform.

re console: i have some patches to the linux hostkit that rip out 
the custom R3 line reader

this in itself is already an improvement on linux, as rlwrap is, 
at the moment, far superior the the line reading abilities of the 
r3 hostkit

but based on this, i have also hooked up libreadline into the r3 
hostkit, in a very basic way

Gabriele, can WeTan get posted to DevBase? There is an area for community 
projects. You could make a folder for your MD3 stuff.

Andreas, are you using LibReadLine?

that's proper line editing as well as line history

yes, sure

Nice

it's still a quite rough integration as e.g. signals (esc, C-c) are 
not yet handled properly

but it's already rather nice to use :)

Gab said wetan was in the r3 alpha file share .. where ever that 
might be ...

It is of limited availability. If we want the tool used for R2 or 
R3 source, it needs to be publically available, and that means DevBase, 
or failing that, some web site. In either case it needs the right 
licensing, but with Gabriele writing it that is unlikely to be an 
issue.

Ok, look under User/Gabriele/'wetan-test.r

there's no license attached to it.

R2/Forward is MIT - it was the least restrictive license I could 
find short of public domain or WTFPL. The FreeBSD license is comparable 
- see opensource.org for details.

Since the network protocols are asynchronous, it seems that we should 
have a common way to supply a callback to the network resource being 
requested ...

so, if we read a page, we supply a call back to the 'read so that 
our callback is passed the data when it is received....

I'd guess so. that is how its done,  in R2 async networking.

At present you have to supply an awake handler to the port ...

Just thinking we need a higher level interface to the network protocols 
to exploit their async nature.

For instance in Jquery .. you just chain functions ....

well, i guess I meant that its how I implemented the handler's switch/case. 
 it just forked off to callbacks.

Too low level I think and messy

Just want something like

read/cb http://www.rebol.com:call-back-function

what I mean is that, like face/feel, the handler is a low-level set 
of functions which should callback to application hooks based on 
events.

you could not... what events does the handler really manage?

could not what?

maybe, if it had an event name parameter.  a bit like the event action. 
 but the scheme handler still needs to exist, its the place where 
logical events are determined.

maybe supply a block .. where the first is the one you want used 
on success, and the other is an error handler

I'd rather it be just a function with error events instead.

but the problem with this is that with a single callback, it gets 
hard to tailor your stuff, cause everything has to happen in a single 
function.  I'd rather have named callbacks.

read/cb http://www.rebol.com'on-done :call-back-function

well, in that case we can use refinements

read/on-done http://www.rebol.com:callback

but each scheme will have its own  callbacks.  some schemes might 
support headers, others not... for example, in my http rss reader, 
I had a callback for the file size.  if it was too large, I'd refuse 
the rest of the read and close the port...

the other problem is that 'read doesn't support these refinements