World: r3wp

... and that is where imo codec system is under-engineered, pushing 
us to introduce read/text :-) Because codecs can work only upon in-memory 
data, not streamed ones. The same for parse :-)

BrianH: looking at everything we are looking for it feels like R3 
is going to be in 3.0 in 10 years :-)

Pekr, on codecs... the question is: where did you put the pipeline?

Carl, while you're here, I was going over the imported tickets in 
CureCode and it looks like some of the tested ones weren't. If I 
can I'm going to review the old tickets to see if they are still 
fixed, or if they ever were, and when.

A codec only works on in-memory data... even at a low level.

Carl - how did Amiga datatypes identify the formats then? I don't 
expect we are going to read 9GB video into memory to find out it 
is an avi container, using filters xvid, version xyz?

Brian, ok... that's good to know.  If it looks time consuming, maybe 
see if we can get some volunteers to help?

I think he wants codecs that work on ports. I figured out how to 
make PARSE work on ports, at least seekable ones...

But - it can come later. I just did not like it created the need 
for read/text, because read/text goes against "Pruning read/write" 
blog, if I understand it correctly.

Pekr, no, you would not write it that way.

BrianH: yes - "continuous parsing" is how I called it some 8 years 
ago :-) Of course, as Maxim said - what if you need to backtrack?

Keep in mind that in R3 the I/O devices are async-by-default.

Hence the "seekable"

So... you build the pipeline in REBOL.... not at the I/O level.

Doc also had one question towards event system, but I can't find 
it. Something along the event loop and if it is part of host code 
and can be changed (?) for libevent for e.g.?

Were did he post it?

Well, those questions are here maybe because we lack few handy diagrams, 
e.g. like you did for Devices blog. But it costs your time, so we 
might prefer you working on that stuff first :-)

Darn, he was just here too - he could have asked himself.

Cheyenne group, I think.

will search for libevent ...

I posted a very detailed description of event handling on the wiki.

I think it covered pretty much the entire thing. But it was a long 
time ago.

Posted by Doc - "Having the TCP/IP part open-sourced in R3 will be 
great. It will allow to use much faster OS hooks for file transfers, 
extend the port! API to bind only on selected interfaces, etc...I 
wonder if the main event loop will be there also, so we can replace 
the not-scalable Select( ) call by other faster ones or even integrate 
libevent. That would definitely make Cheyenne able to handle a much 
higher number of connections."

Anyway for funcs like PARSE... the problem is state-change management.

In reply to Doc's question: yes, that's all open source.

I look forward to seeing Doc and others move it forward, beyond select()... 
and it's other methods.

Concurrency model is interesting topic too. Ppl here were mentioning 
Erlang for e.g. There is lots of stuff to study. If underlying APIs 
are solid, then R3 will be nicely scallable. Sometimes even simple 
change can make big difference. I still wait once some skilled C 
developers changes Windows timers to Multimedia timers :-)

So - when can we expect first plugin? :-)

btw - does plugin mean that I have to have the file separate? Or 
will bundling to one exe be possible?

Plugins can be internalized... so yes, a single exe is supported.

There are a few simple init levels in the host.

In fact, it may even be possible to provide your own R boot image. 
 But, maybe that should be special feature... SDK or something.

(The boot image is the fundamental r boot code bundled into the exe.... 
evalutes native, action, and other boot funcs.)

Ah, good to hear ... it once again starts to sound like MagmaOS/Wildman 
is still a long term plan :-)

Regarding plugin timeline: last week.  :-(     But, so many other 
"problems" popped up, was not possible to make it.

well ... but the OS of future is .... JavaScript :-)

Problems regarding plugin architecture?

No, other things... servers, ISP, DSL, kids, DTV, chicken, wine, 
etc.

Carl, cold you put out the June plan blog a little earlier this time? 
It would help with prioritization of tickets, something that was 
skipped recently because we didn't quuite know what was going on...

Infrastructure.

Water.

Water ** 3.

Wine is infrastructure, yes :)

B: yes, ok, earlier.

yes, earlier, so that AInc. can properly plan on AmigaOS 6 announcement 
:-)

Well, Pekr, you recognize what is happening, no?

Not sure what you mean? Building a future? :-)

As the world moves to Javascript... they return to the same model 
they had before, "code is not really data".... and it's like nothing 
really changed.

They are going in big circles with only small improvements in their 
fundamental computing model.

Doc and I decided that the "block" severity would refer to bugs that 
are stopping development, or the fixing of other bugs. There is only 
one bug with that severity now: DO/next. The system/user/home replacement 
is almost there too.