World: r3wp

I just realized, yes it's quite complicated. :-)

Lightweight
? :-)

Having a play with REBOL3, and after modifying the sliding cat example 
to display data entry areas

instead in the scroll-panel,  I find that I cannot move to the 'next' 
field either by using TAB or CR 

What the 'secret' keystroke required ???

;; ===============================
rebol ["field-scroller.r"]
view [
    h1 "Modified Scrolling (SCROLL-PANEL and SCROLLER)"
    group 2 [
    
        tight bottom right    ; stick the panel to the scrollers
        scroll-panel 150x200 [
        
        datain: group 2 [
        	 label "fld 1 "  area  fld1:
        	 label "fld 2 "  area  fld2: 
        	 label "fld 11 " area  fld1: 
        	 label "fld 21 " area  fld2: 
        	 label "fld 12 " area  fld1: 
        	 label "fld 22 " area  fld2: 
        	 label "fld 13 " area  fld1: 
        	 label "fld 23 " area  fld2: 
        	 label "fld 14 " area  fld1: 
        	 label "fld 24 " area  fld2: 
     			]
         ]
        tight only bottom right
        scroller 20x200
        attach                ; attach scroller and scroll-panel
       tight only top right
        scroller 150x20

        attach -3             ; attach with scroll-panel            
    ]
 
]
;;=================================================

There's no secret keystroke as tabbing has not yet been implemented 
in VID3.

So I can't make any data-entry type forms yet ! When is Tab/Shigt 
Tab expected to be implemented ? Thanks

vid is being re-written by Carl. We're all waiting to see the result.

I would not delve too deeply into the current vid as the new version 
(3.4) is likely to have quite different functionality.

Depending also on Gabriele's motivation and circumstances, VID3 development 
might continue if VID3.4 is very different from VID3. So far no more 
details yet.

Henrik, LDAP is the lightweight reincarnation of X.500 (or X.400, 
I forget all the labels), a really heavyweight directory specification 
from the height of industrial age centralised organisations

Same way XML is the "lightweight" version of SGML

Kaj, I see.

But you're touching on a fundamental problem there. It's impossible 
to explain to people what lightweight is, because everyone thinks 
they're it

REBOL thinks it's it, but I would point you to Adam Dunkel's operating 
system for sensors

I guess LDAP could be considered lightweight compared to its own 
predecessors.

Yep

I mentioned LDAP because I naively thought it meant "a table of names 
and addresses", which I thought it can't be that hard to make. :-)

Oh, they can complicate anything :-)

I think this is why LDAP is still a missing protocol for REBOL

yeah, that must be it.

It's funny though. When I think of something like a name directory, 
I wouldn't build such a complex system that fits everyone and everything, 
which makes it hard to support. I guess it comes with being used 
to working with REBOL for a long time, where I usually cook up custom 
solutions for each problem.

LDAP is really a database, for which you can define your own schema. 
The complexity is closer to a relational database than a basic Internet 
protocol

The same functionality in REBOL wouldn't amount to much, because 
it's fundamental, but LDAP suffers from being implemented with classic 
technology

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.