World: r3wp

They are separate APIs.

But anyway, the main mechanisms are in A55, but the wrappers are 
needed.

Ah. What will be the model to "simulate" R2 DLL capabilities? Ladislav 
suggested bunch of enhancements. Should we do R2 DLL kind of interface 
as one of plugins?

In fact, if you use the lower level (to be hidden) load-plugin on 
any exe or dll, you will see it load and attempt to validate the 
plugin.

Yes, I think so, if possible.

Because, we need people in the community to build the DLL access 
methods.

btw - I can see some new users in R3 Chat - it is a good sign. From 
the point of RT - are you still contacted by new users/companies? 
Is there any interest in R3? Sometimes I feel that we are unnoticed 
:-)

But there are still various issues around it.

Yes, there are always new users coming to the site, and trying things 
(and sending us feedback, etc.)  It goes in waves... (not to be confused 
with google waves.)

As for R3 and me, I can't wait when we get back to GUI. It was good 
period. And times flies by - it is one year you started to work on 
it. The model is good, we "just" need to finish it and allow it to 
display Unicode. Well, some kernel changes are needed too, but if 
gfx is going to be open-sourced, not a problem ...

Let me tell you... I also want to get back to the GUI, and it is 
not easy for me to work on plugin and related code (which is not 
as interesting or cool).

But, I know that once it is available, then it enables many users 
to start using R3 in ways they could not before.  It is an enabler.

There is a certain satisfaction when something difficult falls into 
place. And it's true that it's sometimes not only difficult to design 
and code but difficult to explain. :-)

yes, just don't listen to me - many ppl here prefer interoperability. 
We still miss on protocols, we need DLLs, we need porting (I am buying 
WinCE SmartPhone next week :-)

Yes. And a satisfaction to checking it off on the big todo list. 
;)

We need strong subsystems, so the proper design-work in initial phases 
pays off later ...

I'm looking forward to user-defined datatypes still :)

... 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.)