World: r3wp

It does have a performance advantage, because it scales fairly well

REBOL will need LDAP if it wants to play in the Grid.  Web 3.0?  
Skip it for LCG maybe. Official VDT development tools for the Grid 
are still pretty limited; C, C++. Python, Java, Tcl; not many others. 
 We could play in this arena I think., but it'll require a fair amount 
ot back-filling to get to spec.  But will the grid ever hit consumer 
level?  I think so ... but maybe not.

well, what are we waiting for? :-) what would be the best approach 
to an LDAP client? (or what one calls it)

I think also that whatever is made, should be documented in a cookbook 
recipe.

We'll need access to Berkeley DB too, (if the Grid stays in the current 
shape it is) so a good reason to link to libdb for RIF.


For LDAP, I think the protocol should be in a REBOL scheme.  But 
as stated, it's not a small task.


And for the Grid, we'll need certificate handlers, and encryption 
ports will work nicely for that.  With those three pieces, I think 
we'd be ready to introduce ourselves to the CERN LCG and VDT people 
 (Assuming they didn't shoot down the idea off hand due to not Open 
Source)  In which case we'd have to live outside the inner grid and 
float about the consumer grid.  No science apps would need apply, 
but the consumer grid could be a lucrative next step.  Maybe.

not a small task means we need to divide it into many small steps

wouldn't it be good to get pop3, imap, smtp and ftp back to work 
first?

whatever is easy

What grid uses LDAP and Berkeley DB?

BDB? do you really want to hurt yourself that much? :)

I don't, that's why I'm interested

There was some BDB driver in the past did by Jeff Kreis, but - we 
should refuse any driver with other than SQL .... I am a bit exagerrating 
- but why such arcane DB?

SQL is a lot worse, even, so that doesn't sound like a good idea

worse? :-) That is like refusing TCP in communication. Of course 
you can build your own protocol, if you wish :-)

You talk SQL until the end of time, then

humwhat is the meaning of have yet again a half almost but not quite 
the same LDAPsupport i thought that was the problem within rebol 
?  we start things and never end them

Not to let it leak out too too much; I'm becoming a fan of BDB.  
It's used by OpenCOBOL.  BDB offers up access to ISAM, VSAM, lots. 
 RIF could be based on BDB.  I wouldn't want to RIF out of a SQL 
database.  Records, fields and keys.  He-man.


Kaj; you posted on the other world; but yeah, CERN's Grid is LDAP, 
BDB.  I don't care enough to risk life and limb or anything, but 
it would be nice if the scientist inventors got to see their work 
hit the consumer market somewhat pure of form and not splintered, 
at least once.  They won't.  That's what scientists get for giving 
their shit away I guess.  Morons.  :)


Although is may seem like a hinderance, at least we don't have to 
deal with REBOL the Microsoft edition being different than REBOL 
the Sun edition, being different than REBOLzilla.

Why dont to say what is for, this disscussion is like arguing between 
it is better a car or its engine,  sometimes you want to have comfort 
for rather complicated things let use SQL, sometimes you need only 
quick key-value store, let use kay-value DB (like BDB).

I'd like to hint focus on SQLite, inside it has its own key-value 
engine and now it has even Spatial (2 dimensional) R-tree indexes.

Still in 200kB like code

RIF should be a kind of key-value right?

It was promissed long ago, with some disscussion about associative 
database model right? what is current state of intention? Anybody 
knows?

Perhaps Pekr? ;)

I know nothing. The only thing I know that SQLite is the tinniest 
and still rather functionally sufficient (complex) piece of DB code 
since the slice bread, cross platform. I hope we will make it a plug-in 
at least. But - I still want RIF. RIF as some standard aproach, upon 
which we can build RebolDB engine - then I don't hesitate to use 
one, because it will be lean and mean, and standard ....

Dunno what channel it was, but we were discussing possible native 
REBOL DB default inclusion. I could not remember one Java DB system, 
and now I found it, in case someone would be interested:

http://www.prevayler.org/wiki/


It is Java persistent values storage. Few years ago I looked at it, 
they claimed it can be implemented in some hundreds of lines of code. 
It reminds me in-memory RebDB, I wonder if they solve concurency 
somehow ...

BT: BDB is incompatible across versions, so that whenever you install 
something that uses it it needs to install its own version; it is 
bigger than things like sqlite which are much more powerful; and 
if you need a real thing just use postgres or mysql. BDB is just 
infinite bloat...

Pavel, I'm not sure that RIF determines the format for your data 
records, only for lowlevel storage on disk. Maybe I'm wrong.

If we combine RIF, R/S and REBOL itself, we can get CouchDB in half 
a meg.

Including REBOL, I mean.

Gabriele; True and a good point.   (I miss RMS on the Vax).  I have 
faith that RIF will come, and RIF will rock.

Re BDB;  Found this on the cuil.com main page of a rebol search, 
by fluke of timing more than anything.

http://www.cs.unm.edu/%7Ewhip/   Jeff Kreis' libdb interface.  Works 
great with 2.7.6 and the freed load/library.  I just had to tweak 
Jeff's libdb.c to use my setup and to get around that pesky incompatibilty 
that I blame on Gabriele now  :)

the discution on the R3 blog about text-options allowed me to enhance 
my RTE line so with a dedicace to graham here is the new version. 
http://shadwolf.free.fr/RTE-line-Shad-06.r^^

:)

so do you notice the change in performance graham  ?

not tried yet ... busy busy busy!

Much faster!

thank you ^^

well  with 10 times less datas that's obvious

data = plural.

datum = singular :)

so for the text-option i like the idea but  I agree that's not applyable 
to dynamic drawblock generation

( it's Latin ... not English )

ok so datas ;P

cause i'm me and hum I do what please me that's what the concept 
of freedom is all about  :P

the concept of freedom is another channel !

graham i'm kiding thank you for the explanation ^^...

Has anyone given any thought to what printing model R3 is going to 
use?

as in printing to physical printers?

On behalf of Graham: Yes as in printing to real printers.

That's going to be very difficult unless we simply employ some form 
of postscript output, similar to VID.