World: r3wp

I will think in a better data scheme too because the way it's designed 
it's not to handle big text amount anyway ...

on my previous intent i was handeling the text as a subdivision of 
same way formated strings of char  and that was a pain then to get 
a precise text cursor motion and to insert new chars into an already 
existing and formated string

so with the actual way to handle the data each char haves it's own 
position and format stored that enhance alot the précision and the 
posibilities but the side effect is to have to handle much more data

a way to reduce the data scheme will be to hum encode them into a 
fixed size string for example a12black for arial black 12 pt char 
 instead of storing for each char the corresponding values as splited 
 thing

i use as "index" for my seachies into the list the offset position 
of each char displayed

so my idea to speed the search process instead of having to use foreach 
loops would be to convert my list into an hash table like data structure 
using the postions as index

and i need to find a good way to handle multiline fonctionalities

in multiline statement the most problematical issue is to deal with 
the multilne text selection and to deal with  the text wraping

some more evolutions http://shadwolf.free.fr/RTE-line-Shad05.rthis 
version gets some bugs corrections, no active probe and the handling 
of the del. key

http://shadwolf.free.fr/RTE-line-Shad-05.r

No Rebol3 Frontline blog entry for 57 days
No Rebol3 updates to Docbase for 70  days
Grape picking season approaching

perhaps something has been brewing in the vats?

yep very quiet

It would helpful if there were some community driven projects for 
designing R3 protocols. This is something that Carl doesn't need 
to be involved in until final inspection to see if it can be added 
as standard to R3. Although it's been said by Carl that he would 
change the TCP ports a bit as they were found to be too simple, I 
don't think it would be much of a hindrance to work on simpler protocols.


I wouldn't mind seeing out of the box support for LDAP, if it can 
be done in 4-5 kb of code. I know DICT is being worked on.

(I know next to nothing about LDAP, so 4-5 kb of code may be ludicrous)

The full feature set of LDAP is quite complicated, but I think a 
basic interface would already help a lot

Even if it were just read-only at first

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?