World: r4wp

Been doing that for a decade

:D

Will we also have a system object structure? I liked lurking in the 
internals of REBOL in initial days :-)

Already in Red/System

Addimg CGI support early would be good ... for online demos

You can do it in Red/System

Without proper internal sandboxing, you certainly wouldn't want to 
give open access to anyone for running Red (and even worse Red/System) 
code on your server.

Once again, the best option for such live demos is adding a thin 
Red emulation layer on top of Topaz.

On TryREBOL it's no problem. I've been giving the world a gaping 
hole into our server for three years now. It was a test, and people 
tried to break it, but they never got in

CGI is based on the same principle. It's supposed to be a gateway 
from a Unix web server to a Unix file system, so you can secure it 
with operating system tools

I think you'd run it on your own server ...

Just skimming this group. Exciting to see so much going on here.

Adding CGI would be good for online demo's? Well for building web-sites 
too! Finally drop php.

Aren't you using Doc's Cheyenne server? ;-)

Unfortunately my websitehoster has a plesk system with Apache on 
it. I managed to have REBOL CGI working on it. It will process .r 
.rsp files.

Having more freedom often means to pay more

Or run your own server

or local server which generates static content for your public server 
hosting

I do that, too, but there's no CGI there, then

Doc, with recent discussions about Unicode, I wonder if we will have 
strong binary type, and myriads of to-* REBOL-like functions for 
various conversions between the types?

Pekr: there's only one TO native, all the to-* functions are just 
handy wrappers. How would you suggest datatype conversions be handled 
instead?

dunno. Just want to avoid R2 mess with binary vs string conversion, 
etc.

We did a lot in R3 to clean up binary vs. string conversion. There's 
probably more work to do, but it's a good start.

I know, so I hope Red follows R3 model :-)

The one thing R3 was bereft in was custom conversion functions. We 
had some ideas, but for the most part didn't get around to implementing 
them.

do you mean codecs?

Well, that too, but I more meant a better replacement for that awkward 
struct! conversion hack in R2.

Hello, I want to use a local database whith no concurency for aor 
the moment I see ndb indexed btree from Dockimbel, another alternative 
is possible and what ca be used  with the future red ?

at the moment there is a Red/System binding to SQLite. But that's 
for Red/System. I would probably wait, till higher level Red is more 
feature complete in upcoming 2-3 months ...

Daniel: welcome! The best choice so far would be SQLite for such 
usage. We might reuse lower level parts of SQLite to build our own 
storage system specifically designed for Red.

Yes, SQLite is a good candidate for that imo. Right licence, relatively 
small, performance is good.

OK, and also dispo in android I think and bbrerry os...

well, as for BB 10 - we should get there imo - QNX based, old Amiga 
friends :-) And maybe it is good to support lower market, than crowded 
iOS developer's base? We will see ...

That will be very good, shure ! :)

We'll spread wherever possible! :-)

If you're thinking of adapting the lower levels of SQLite for our 
use, start with SQLite 4. It's much better suited for that kind of 
thing.

What's the status of that?

All I know is here: http://www.sqlite.org/src4/doc/trunk/www/index.wiki

I suspect that it's in alpha. Still, just due to the system structure, 
even an alpha version would be easier to adapt than the stable SQLite 
< 4.

It is structures as a NoSQL-style key/value store with a SQL engine 
on top. We can put our own engine on top.

We might even be able to implement the API that the storage engines 
plug into, which would allow us to use the storage engines unchanged.

Brian: that last shortest path might be the first thing to try.

Agreed. And it will be easier to keep an API clone updated for future 
SQLite changes, so we can get the benefits of future improvements 
to the storage engines.

SQLite already went through the trouble of extracing and abstracting 
their storage engines, so it's best to reuse their work :)

We certainly have better ways to spend your time than debugging SQLite 
internals, so keeping the same SQLite codebase subset seems the right 
thing to do.

Well, what I would like to see is the ability to have one file per 
table, without artificial limits like having to attach databases, 
to some artificial number of 9, or what was the limit. Second - SQLite 
4 to have encryption storage option ....

Also some record level locking would be nice to have ...

If you want one file per table, pick another engine. For the rest 
of that stuff SQLite is OK.

Yes, it would really help to more easily backup at the file level 
- not just one monstrous file each time, but certain tables ...

there is no other option to SQLite, other embedded databases are 
either not free, or don't use SQL syntax (e.g. mySQL)