World: r3wp

system/options/cgi

hmm - so where is the right place for such stuff?

Do we want to put it into external module? Then we are stripping 
out important stuff from R3, making it less compact than R2

hmm, Max lobbing for user dtypes :-)

Making a module, even a community library, is the best way to get 
the more complex stuff in. Post it to DevBase, start the discussion, 
get it refined, and then it may be incorporated, or may not be. Don't 
waste all of the work I did to get the module system working.

is there any new work version of REPLACE ?

The new REPLACE would be native, and noone has made any proposed 
source or even spec yet. Still under discussion.

BrianH: it is not about wasting. I just want we don't do fatal mistake 
- pretending we order users how they should use R3. R3 would be already 
used by many ppl, but is not, due of following reasons:

- missing network protocols, proxy
- call incompletness in comparison to R2
- weird console
- missing CGI mode
- missing DB protocols


No matter how your module system is usefull, if we don't provide 
users with R2 level completness, we are doing fatal mistake ...

CGI mode is only missing on Windows (and might be on OSX - noone 
has checked yet). CGI works just fine on Linux.

As for where the right place to put the CGI environment variables, 
R3 currently leaves them in the environment, and uses GET-ENV to 
get at them. When system/options/cgi was first created, REBOL didn't 
have a user-accessible GET-ENV function. You could easily write a 
REBOL function that could construct an object containing all of the 
information passed to a CGI process, but that function and that object 
would be web-server-specific.

However, you are missing the whole point of the module system: R3 
won't be as monolithic as R2, and will have fewer mezzanines, not 
more, on purpose. We are trying to make R3 cleaner than R2, and easier 
to customize for your specific use. That means less built in, and 
more added on, in some cases from a common library of modules that 
the community maintains. Non-CGI apps don't need CGI mezzanines.

This is also why the extension model was so important - not everyone 
needs SQLite either, but the people who do *really* need it.

Max just proposed interesting way to implement utypes on R3 chat.

probably, we should use APPLY :find in REPLACE to allow more options, 
no ?

REPLACE has as many options as it can handle. The overhead of managing 
all of the REPLACE refinements is reaching the point of diminishing 
returns. The main problem of REPLACE isn't flexibility, it's performance.

Re user types, Its just that I've realised a common theme in the 
last weeks, and they all can be handled via a simple user type datatype. 
 They wouldn't need any C coding and can start very simple and be 
augmented as usage gives us valuable feedback.


Coupled with extensions, they could be a VERY interesting way to 
add toolsets to REBOL. (just like people do it in python  ;-)  


I could very easily wrap liquid, as an example, and allow completely 
invisible dataflow to some extent!  It would take me less than an 
hour to do with what I propose (once liquid works in R3).

BrianH, what's a quick check for CGI?

I don't really know - I'd have to look up the CGI specs and write 
a script. I don't have Linux working here locally, so I can't experiment.

hum for multimedia extension we should choose things partable and 
on public domaine i think ...

it's easy to make a VID front end to pilot a oggvorbis player for 
example it's more difficult to mix VID and opengl.

actually it isn't hard to mix VID and OpenGL  :-)  all we need is 
a way to do a quick memcopy of the OpenGL pixel buffer into an image! 
datatype... that's it.  really simple.


now I dont want to be forced into using View though.  I want to be 
able to use extensions to control the windowing too.  I need to be 
able to use other window managers if I want to integrate into better 
engine which are already ported to all major platforms.  Things like 
open scene graph or other game-oriented 3D engine, DirectX, whatever.

even use precise timers and trigger rebol code... for high-end audio 
and video editing, and working with specialized media hardware too... 
this is essential.

extensions are the key to liberating REBOL from its platform limits. 
 just like python can focus on its core, all the rest is modular 
and is maintained by other people, not Guido.


once I get the OpenGL extension working to some basic level, RT will 
never need to support it, I am pretty sure, John, Cyphre, Henrik, 
Anton, I and others will be able to give it a life of its own, all 
that RT will have to do is provide a link to it on its own site and 
say that R3 supports OpenGL natively.


same for sqlite and pekr, and many other tools many of us use daily 
and wish we could manage with rebol instead.

pekr is a tool??

For me View is still being essential product. I want HW accelerated 
View, either by linking to DirectX, using JitBlit or other technique. 
I don't want unprecise 3D crap ...

Device interfacing was officialy added to project-plan. It is a good 
sign it will come, along with image and vector datatype support. 
No callbacks yet though ....

find/first for multiple targets ... interesting - never heard of 
that proposal ....

Carl`s reaction on the R3 chat wrt callbacks sort of seems to imply 
that he likes my callback idea and it might make the cut for extensions. 
 crossing my fingers.

pekr, once you see what can be done with a 3D engine you won't call 
it crap... believe me.  Apple's GUI is based on a 3D engine, which 
I believe is based on OpenGL... can't remember precisely.  same thing 
for vista's aero which is based on DirectX which also uses 3D.

3D allows us to use sub-pixel rendering which is actually more precise 
than AGG.  and if you don't use fancy shaders and effects, the rendering 
will be sooo similar as to not even be measurably different.

I will correct my previous statement... AGG can do sub-pixel stuff 
too... but our use of integer pair! datatypes limit us to pixel coordinates 
within view.

Max - unless my GUI looks precisely the same on all systems, I don't 
want to use it, easy as that. So - give a call to gfx card and driver 
makers, and try to standardise that :-)

Anyone is free to do anything. What I don't like is early split. 
I think that R3 without View has little sense. Who thinks that Core 
will make it, is imo mistaken. What would be browser plugin good 
for, if it would be Core only - there is no point in making such 
a plugin. And what GUI will we get? Multimegabyte SDL linked one? 
No VID?

no one said there will be no VID.

OK then ... because VID like methodology of GUI creation is the correct 
answer to go simple GUIs. Remember that JavaFX has stolen some ideas 
from View - just look at the GUI syntax - so close ...

I use REBOL to solve problems, please clients and get work done. 
 I also want to start doing some gaming and I really want to use 
OGL and REBOL so it can be cross platform and very fast with the 
minimal fuss.

but again, this pixel perfect idea isn't what its all hyped up to 
be.

even current VID can't deliver on that since it can't guarantee the 
same fonts on all OSes.

and many clients DONT want custom guis... they want OS look and features 
which are OS native, like D&D, spotlight menu integration on OSX, 
system tray on windows, etc etc.

I prefer one well supported engine instead of 10 less supported. 
Everybody is free to do anything. What I don't like is, that sometimes 
new stuff distracts the crowd and splits the effort. In the same 
way I think that VID Ext Kit, in current days, is contraproductive 
product, but this is just my opinion.

If you do OS native look, you kill REBOL ....

We have to have our own face. The custom GUI is not the problem. 
The problem always was in its behavioral area - we need system compatible 
behaviour and deployment.

you forget that many of us actually use REBOL to feed our families 
 ;-)


R3 won't allow that for me until at least 6 months... and that's 
if the extension get extended enough.  otherwise, I have *Absolutely* 
no incentive to move to R3 right now.

I don't understand your point

why would using OS integration kill REBOL... its the first complaint 
I have EVERY time I deliver an application to a client...  its not 
integrated into the OS.

I am not against integration. I am against making View using native 
OS widgets ...

for me, the GUI dialect should be completely separate from its implementation. 
 so that one can reuse the dialect in another engine he needs.

pekr... clients pay for applications... who cares what we want... 
they are the one ultimately driving what we need REBOL for.

Maxim - I might not care. This is just one measure, what client want. 
I provided clients with many solutions, from DOS apps via Windows 
native apps, some web apps, and VID/RebGUI small apps. They don't 
care.

If you say, that Carl should implement in R3 what clients want, then 
we as well might end-up with totally different R3 than we have :-)