World: r3wp

latest view is 2.5.x or something like that

I would guess 2.5.6, the last version before the 2.6 series. Other 
platforms were dropped after 2.5.0 (like WinCE).

I can't see why they  wouldn't ...as that means they can offer pretty 
much the whole stack ....  OpenSolaris, Mysql, Apache, PHP

Still, suggest it. It's more likely for platforms that can be put 
in a VM for testing, for free (no cost).

VirtualBox of course supports OpenSolaris .. I installed it last 
night

since Oracle also owns VirtualBox

I found that OpenSolaris is awfully slow even when compared to slow 
Linux distributions like Ubuntu but that may be just my computer 
since OpenSolaris doesn't support that much hardware. Booting it 
took 10 minutes already but the whole system felt very sluggish. 
Some of the features it has are really nice though. The ZFS video 
where some guy used a big hammer to destroy running harddrives to 
show off ZFS handling it without any problems was cool :) What I 
would like to see Rebol run on is Haiku, especially since you develop 
native apps for it with C++ which usually is quite horrible although 
I have to say that the BeOS api makes C++ programming quite a bit 
less horrible.

Haiku support is likely to happen with R3, but we'll have to see 
with R2. Was there a previous BeOS port of R2?

If so we'd need a new minor platform number for Haiku with the new 
GCC compiler.

Yeah there is a Rebol/Core 2.5.0.5.2 and a Rebol/View 1.2.1.5.2 for 
BeOS R5. I tried the one with View on the latest nightly build of 
Haiku yesterday, didn't work though, some error message about the 
Media Server Addon IIRC. Could be because I used the GCC4 hybrid 
iso, don't know how far they are with that stuff yet, I haven't followed 
the mailing list for a few months. A R3 port in a few years would 
be good enough for me, Haiku is still in alpha so it's probably a 
good idea to wait a bit more. From what I heard they now have a few 
people working on it full time (paid) thanks to a lot of donations, 
so there is a lot of stuff going on with the Haiku code base right 
now :)

We'll keep you in mind as being a possible Haiku tester :)

Yay, do I get a t-shirt? :) Or at least a button "ask me about Haiku 
R3".

full ack BC, graham if you need (like) zfs try freebsd, it's already 
there. 
better perfomance, cleaner handling and much faster than linux. 

if you need a wm try xfce or lxde. feels like running win 3.11 on 
a quadcore.


for rdbms look also at monetdb, in nearly all cases 5-10 times faster 
than mysql.

very advanced designed dbserver and a nice abstracted query layer 
for sql and xquery. 

if you need a good allrounder/workhorse try postgresql (scales good 
on multicore)

free- or netbsd is a solid base for this. (but only until a real 
smp ready microkernel
os like minix is finished :-)

Any Rebol drivers for monetdb ?  :)

MonetDB looks nice, and it has ODBC drivers for a start. Column store 
is good for analytics.

But from Linux?

There is apparently a TCP interface, so drivers could be written 
that would take advantage of its strengths better than ODBC would.

Which reminds me, what's stopping RT from supporting unixodbc?  I 
think Carl said there was a proliferation of odbc methods for Linux, 
but as far as I can tell they've now standardized on unixodbc

And you can use unixodbc on Linux (but can you use it from R2 on 
Linux?).

Sorry, missed your message :)

I had a quick search for the TCP/IP interface docs .. couldn't find 
any yet

To answer your question, my guess would be time and money. R2 native 
enhancements that RT doesn't need itself need to be funded nowadays.

http://monetdb.cwi.nl/SQL/Documentation/Programming-Interfaces.html

OK, text protocol over TCP or SSL. That sounds doable.

Presumably that is handled by their library

ODBC is there to avoid having to write drivers to every db under 
the sun ...

Carl says the Windows Rebol ODBC source is only two pages of C code 
...

Nice. Have him post it to DevBase in an appropriate directory so 
we can improve it :)

Looks like the best approach to MonetDB support for R2 would be to 
look at the source of the Python driver, which is pure Python, no 
C.

Links to how to program unixODBC http://www.unixodbc.org/doc/ProgrammerManual/Tutorial/

graham I am using a 'prototype multi cli connector' for different 
databases.

(currently mysql/postgresql/monetdb/sqlite. more are in progress) 
I will provide you

with a source link in a couple of days if you like. I would never 
ever use odbc, it's to unstable

and makes always problems when the db load is highest. but ok I also 
don't like synthetical 

benchmarks or theoretical feature lists. real life experiences are 
best...

interesting ... please

Got any more information?

like this?
the cli connector is using the cli component nearly all major
databases delivering. the connection is made via rebols 

call/wait/info/output/error and a simple parse after, for the resultset.
I am using this prototype mainly for a q & d connect

to mysql/postgresql/monetdb/sqlite. on my list are also connectors 
for

firebird/oracle/greenplum/sybase/ingres/infobright/frontbase and 
cassandra.
pros:

1. very fast for single requests
2. no rewrite of code needed if a new version or protocol is out
3. easy 'data migration' between the db's

4. adding new db's are a matter of hours only (see the cli spec thats 
all)
5. fast prototyping and testing for new db's

6. robust, never had any trouble with cli's even with bigger resultsets

7. should be perfect also for traditional cgi (the process starting 
overhead is minimal, execpt you name is facebook)

8. very small footprint (~120 lines for connecting to 4 db's, could 
be the half)

with a nice tcp-server component like rebservice the 
cli multi connector could be very usefull as a c/s connector.
I made a test with 2.000 concurrent calls (simple select) 
on a 4 gig quadcore. the cpu was only close to 50%, a good value.

cons:


1. slow if you have very much serial inserts (unless you shape them 
into one sql query)
2. need to start a cli process for every request
3. needs a tcp server for non-local connections
4. some more, but who cares ;-)

with a solution to keep the cli open from rebservice,

these cons could disappear and the speed diff overhead to a memory 
based lib
could be marginal.

2'000 concurrent calls ??

yes

How did you do that?

call without /wait in a loop

ok

to keep the cli open, using telnet into localhost ?

well if this is working the connector will be great. this weekend 
I can post the source so far...

the test I made was against a real big table with 50+ mio records. 
no problem at all.

I wonder how it works inserting large text ( blobs )

I don't see any problem. cli's are also used for very large dumps 
or restores.

as said I am impressed by the robustness of this approach.

Ok, I'm waiting for the report on Saturday

sure captain ;-)

I'm getting my red pencil ready :)

:-))

will post the link saturday into the db group.