World: r3wp

BrianH R3 is open source but not open access.... hihihihihihi

My point is if you want dianamic particiapation on enhancements in 
rebol3 anyone should be able to access the  whole code as "reader" 
at least. I mean for example i want to bring a sql-protocol like 
enhancement but able to be used in the inner most layer of  rebol 
VM ...  if i can read the source code of the whole WM that allows 
me to get a better understanding on how the layers are made and how 
to do my intgration then I can come with my proposal and "offer it" 
to RT rt keeps the final word on new things integration based on 
community work . RT so remains the controler and the single diffusion 
source of retail R3 VM ...

shadwolf - nonsense and excuse.

You can implement SQL protocol with the knowledge of REBOL level 
stuff, plus e.g. extensions. For mySQL (socket based), you don't 
even need extensions. The only thing I can see is missing, is good 
enough docs ...

Have you EVER looked into mySQL, postgress or SQLite protocol sources? 
Becuase I did, I even helped to fix them. There is no single bit 
of REBOL VM, which would help me to understand or fix the protocol. 
Hence - I can see your post as typical pro-open-source rant :-)

But, in the end, I just don't know - if it really would make you 
happier, maybe RT should consider at least SDK level read-only licence 
of REBOL :-)

pekr i was one of the first in seeing them :P

and they are made that way because at that time rebol VM  was closed 
and obdc:// layer wasn't a default "open" solution...

Just answer to yourself - if you would get those sources right now 
- would it somehow magically make you more active in rebol scene?

pekr why using net sockets when you have even faster better ways 
to access the data in you base

with mySQL? ok, here we go - tell me :-)

Pekr the difference is that doing a script passing commands through 
net sockets and dialect translation isn't the fastest way ... but 
it's the easier to implement and even so when you don't have access 
to the direct content of the "black box"

What's missing is a REBOL storage mechanism like RIF which would 
enable developers to layer an access API (such as SQL) on top.

I took SQL things as an example because Carl was rubbing his head 
on a the wall trying to figure out what "SQL  like language" was 
the most suited to integer in the VM . But yes my be i understoud 
it the wrong way...  thing is SQL server are out of the box things 
and it would be better imho to keep them as external script doing 
the way we done them until now. I'm not sure we would benefit integrated 
them into the "black box" (R3 VM) if we then don't have the means 
to follow the product update...  If that's to produce a VM able to 
talk to a precise SQL server version under spécific circontancies 
I don't see that as a gain ...  AT least the scripted way is easy 
to maintain and run the same way under most circonstancies.

Shadwolf - I think that parsing SQL commands and results over sockets 
is not the most intensive and time consuming thing in DB area. The 
most of the work is done by the SQL engine itself ;-)

Ashley - I wonder what will happen to RIF ... no words on it, so 
imo it will not be done for 3.0, maybe 3.1

pekr yeah but when you computer is already filled with HTTP request 
adding more "SQL requests" slow downs your HTTP or at least that's 
the way i see it and that maybe too why all the database builders 
created another entry point called odbc

r3.0  will be only core right ?

Shadwolf - I am not dismissing opensourcing REBOL. I just try to 
point out, that open-sourcing it now would not bring us any significant 
advantage. It would not bring us hundreds of coders suddenly, being 
able to add good and quality code, so that Carl could accept it. 
I am for finishing Beta plan = finishing Core to the level of satisfaction 
and THEN releasing the Host code = everything except the interpreter. 
Interpreter code can be released later ...

pekr ... who open source a software in alpha stage ? (a part me but 
i'm special  ^^ )

3.0 beta? Dunno. There will be View in it, but not sure it will be 
finished. I expect it being Core release. But -look at beta plan 
here:

http://www.rebol.com/r3/project-plans.html

Carl even agreed to adapt list, to make it wikified, so that we could 
update it for the final beta list ...

cool so when VID 3 work starts again before or after new year's eve 
?

I think before ...

but we can't be sure. R3 progress in last year is good enough, at 
least for me. I am satisfied. If you will ask folks here, we would 
have some trouble to agree, upon what should be next. I like VID3, 
so I would like if View evolved a bit, but many others might prefer 
core stuff as tasking for e.g.

yeah with often ralpha release at least we have time to test and 
find most of the bugs and that makes the wrok more dynamic... In 
comparasion of the way the rebol implementation was done and how 
it's done now I from far prefere the actual way and it's getting 
our small community tigher to Carl ...

Shadwolf, Carl wasn't looking for a "SQL like language" to embed 
in REBOL, he was looking at projects like SQLite to see if he could 
extract their table engine and use it directly without using SQL 
at all. This was for RIF (REBOL Indexed Files).

who open source a software in alpha stage

 - Most open source projects do this. And most open source projects 
 never get out of the alpha phase, because open sourcing a project 
 doesn't get it done faster - most people don't contribute, period.

I agree Pekr, R3 progress has been excellent, the project plan is 
solid and focused for an effort of this size.  Things have really 
picked up in a good way.

I want RIF, I want VID3, but I will be happy with the 3.0 beta without 
either, especially with extensions as a good way to work other options.

As soon as we get device extensions, SQLite can be wrapped, as well 
as any other DB with native libraries with compatible licenses (meaning: 
not MySQL). MySQL could be worked on right now through TCP.

BrianH: why do we need Device Extensions for DBs? To have it async? 
Because - DBs could be wrapped even now, no?

Carl replied to the stack size question:


Re #5530: Pekr, looks like a bug. The current stack limit is set 
to 400000. However, it is an arbitrary number. It can be user setable.

The 
PARSE limit can be made to use the entire C stack, rather than a 
forced limit.

is the project list on any wiki page at this point?

(Relating to Carl's surprise appearance on monday... darn... where 
was I on monday!)

not yet, and I wonder if Carl will make it. He's into parse right 
now ... we will see, we can always remind him of that ...

ok, I would have added my extension example there right away...


 its funny cause he made devbase so we would have a channel to speak 
 with him within R3... then I use it posting callback proposition. 
  a few days later, he asks me where I put it (it sticks out in the 
 extensions groups quite a bit).  Si I give him back the link to the 
 original post....


 and a bit more than week later... he says here that he doesn't know 
 where the source to my extension callbacks stuff is... <sigh>  

Carl really needs a brain maid  ;-)

Pekr, we need device extensions so the database's event flow (callbacks, 
incremental calls, whatever) can synchronize with that of R3.

Without devices you won't be able to specify which task is handling 
the events, and how the events will fit into R3's event model.

You won't need new devices for TCP-accessible databases because there 
is already a TCP device.

Yes, Petr, parse a map! - parse make map! ["one" "two"]["one" "two"]

PARSE is ordered, and maps don't have persistent ordering. Iterators 
and queries are better for maps.

Think SQL-style set query operations.

Nice - http://freebol.org/private/tryrebol/

oh, this is web-public, I just read the request of author to not 
publish it publicly yet ... hopefully it is used by the community 
at max ...

it doesn't work for me. returns empty lines.

it does work for me in FF 3.5 and IE 7

Works for me in Firefox too....But the site has some security flaws, 
so not yet ready for the big time.

The sideswipes at REBOL at the end of the (very short) interactive 
demo suggest that HF had some frustrations in creating the demo site 
:)

what is the base of the frustrations?

Some technical issues in getting it to work; and the apparent lack 
of willing in Rt to fix these problems....There are under six pages 
of tutorial, so it is easy to get to.

authors of various TryREBOL systems seem to have problem with persistence. 
Wouldn't Cheyenne be of some help here? By simple cookie you could 
identify the client and have one console session for him started. 
Cookie would expire at browser's end, or with zero activity for 15 
minutes for e.g. Is there anything I am missing here?

there would be a need for a session manager and process manager. 
I think, something like R3 Uniserve.