World: r3wp

the actual "REBOL" :)

(again, i can only speak for how things were in 2007 or so)

the DLL is the closed part, I suppose. The executable contains the 
open parts.

Ideally one should be able to load the dll into another language 
to use it

I think that's one of the intentions of the DLL.

and one of those languages should be r2

except it sound like R2 is not up for the job.

the single DLL can't imo work. It just contains language interpreter 
plus api structures on the surface imo. It means e.g. all networking 
code (simply code that does something), or OS dependant functions, 
will be in the host kit, hence I am not sure the DLL itself is much 
usefull separately ...

the gui and parser ....

The DLL is the plain Rebol interpreter. All the sourrindings, named 
host-kit, that you need to make use of Rebol on a particular platform 
is in the EXE. The EXE loads the DLL at init time.

As the interpreter is plain C is should be portable to different 
platforms very fast. That's something that Carl always needs to do. 
Than all the host-kit stuff (meaning the interfaces to the Rebol 
interpreter) need to be ported to the target platform.

For example: If you can't get AGG to work, you need to do a replacement 
with an equal API layer.

Graham, I don't see a real good case to use the R3 DLL within R2. 
Why to do this? And the interpreter in the DLL is nothing "useful" 
on it's own. It requires at least a simple host environment to do 
something useful.

In situations where the app can not be ported to R3 yet

Than stay with R2. The effort it takes to mix these two should better 
be spent on porting the app.

Let us know when we have SSL

With the host-kit SSL can be added by the community.

The host of the hostkit can itself be a dll, and that dll could be 
designed to be loaded by R2.

Passing data between them would likely require serialization, just 
like with TCP, but it would be in-memory.

yes I have a client which would benefit from R3 within R2 specificaly 
to use PARSE..   as brian noted, I'd compile the R3 host as a dll 
and try to make a routine in R2 to access it.

any news on R3 GUI front? :-)

some refinements to the resizing model, by ladislav and cyphre as 
well as some documentation, so I can learn how it works. no new demos 
at this time.

What is the plan towards low-level of GUI? I mean - we now have new 
model - host-kit. My understanding is, that Carl created only few 
API functions, to get it running. So - how long will it take for 
VID being able to work upon new host-kit architecture?

Maybe my understanding is wrong, and all api is done already?

VID shouldn't be affected. The host-kit change with the low-level 
part: VID | VIew | Rebol Core | AGG | OS. We need to implement all 
DRAW commands yet.

From the API point-of-view, VID should not be affected, but - if 
you don't have all draw commands implemented yet, it can't work yet, 
no?

Yep, that's why we need to implement them now.

OK, now I understand - I was just trying to understand, what is currently 
happening :-) Any ETA for the transition? 1 month, more? :-)

so we just have some primitives again?

This AGG stuff is pretty old ... has copyright from 2005

transition shouldn't affect GUI development. it's not like all copies 
of A97 stopped working. :-)

AGG 2.4 has the BSD license and 2.5 ( seems work stopped in 2007 
or before ) has the GPL license.

So, I guess we're stuck with 2.4 unless we can find something else

Graham - we use AGG 2.4, because with 2.5, Max changed license to 
GPL. But Cyphe said, that there is not much new in 2.5. AGG is a 
dead-end anyway - it is not further developed by original author 
(Max Shemanarev) imo, but still good.

So, what are the alternatives?

OpenGL

no, Cairo ... but AGG is still better than Cairo, so why to worry? 
And even if Max does not develop it further, maybe AGG community 
will come with some other improvements ...

We can enhance agg ourself, I guess.

so far we're not even taking 100% advantage of AGG, so there's a 
bit of juice left in it.

Yep, there are some interesting methods, like bounding_rect or so 
(to calculate the bounding coords of a shape)

rather than enhance AGG 2.4 .. why not move to OpenGL ?

We then get access to all the 3D stuff and physics models

I'm not sure openGL can cover what AGG does and vice versa.

so both are in a way relevant

Henrik, something really interesting would be a method to get back 
all the constructed vertices (after transformations).
As a shape block.

Don't know if I'm clear

I see AmigaOS4.1 uses cairo

Graham, yes, since Hyperion are so insistant on making AmigaOS look 
like any other linux that is of course what they would use.

Steeve, Cyphre probably understands that better than me, but I assume 
this means some level of hardware acceleration possibility of DRAW 
transformations. :-)

I see Cairo has both PS and PDF as output targets ... which sounds 
really good to me!