World: r3wp

The chat database will be tiny enough for months. We aren't even 
done with the feature set. The internals can change easily. There 
are less than 700 messages, and we don't start having problems til 
100000. I think we have time for this.

I only reacted with your false statement, that it's easy to modify 
the chat to kill the memory overhead.
You didn't studied it carrefully enough.

I know there is no chance that Carl and other gurrus follow my advices.
But I know i'm right, i hope you will not regret it later...

I didn't dispute your statement, just its urgency. Priorities.

700 messages in 3 weeks, with 5 regular users, you're according my 
point.

Many eyes make bugs shallow. We need more developers, which means 
we need a public release. Priorities. We can fix chat *after* the 
public release. As it is, getting the file store in place is a more 
pressing need. That way we can release and track the source. Once 
the source is released we can make fixes as needed. The priority 
needs to be on testing R3 itself, not the chat client. We aren't 
even going to start the GUI chat client until after the R3 public 
release.

It's good to see a little realism about the scope of R3 when Carl 
posted this in RebDev:

Regarding RIF, it will be in 3.1 (not 3.0) and it will provide a 
lot of the 

virtualness" needed for what I think your goal is (to have very large 
blocks for large datasets)."

From what I understood, RIF would have several advantages compared 
to a mezz-level approach :

- fast indexed storage engine in C (probably btree indexes as sqlite 
storage layer was considered for RIF)

- no LOAD/MOLD overhead (direct reading/writing of values in memory)

I wonder if it would preserve bindings? I can't see how...

I guess that the drawback is that RIF would probably be hidden in 
the Core part, so not open sourced.

Or it could be a UDT.

Probably if R3.1 takes another 3-4 years to be done ;-)

Just be thankful R3 is not a 100 year language like Paul Graham's 
ARC.

Steeve, as long as you're using a decent OS, any database should 
be kept all in memory regardless of size. Otherwise, you need a DBMS 
and a DBA.

Yes, some DBAs can do amazing things wih disks (disk tuning is a 
good selection criterion for a DBA)

Gabriele, it's your opnion not mine. we shouln't have to use DBMS 
or other external products (having to install them) for rebol applications 
which are standalone and not multi-user.

The file scheme of Rebol can do the job with a simple scheme wrapper 
(to hide complexity).

This has been requested by the community since long time ago. If 
you don't see the interest, good for you but let the other hope.

I have big long cutting knifes in my kitchen ! Who wants one ? It 
can help you finding who is right or wrong in a more funny (gore) 
manner ;-)

By the way, as Brian say, RebDev can stay as it is for a moment. 
It's simple Rebol data, so it could be easily transform to whatever 
new storage mechanism is needed when the time will require.

And, I don't think the client need to load the whole msgs db as most 
of the time (99.9%) user just read the lasts msgs. So It can be changed 
to cache last 10000 msgs and will only deal with the full db if user 
ask it to do (ie : search).


And to finnish, 24MB is not much for 100'000 msgs. I would not bother 
until it reach 200MB (It's what FF3 take after half a day of surfing) 
so I have 800'000 msgs left :-)

About protocols: Carl says that the basic foundation is not going 
to change, so he wants to see some protocols written. He wants to 
start with something simple like Finger. Here's your chance to contribute!

Carl: "most of the scheme structure has been solid and unchanged 
for more than a year. The main disruption was Unicode, but that's 
been done for a while too. I think we should pick a few very simple 
protocols, maybe one like Finger, and j ust show how they are done... 
as an example."

No Didec to work as you wish, rebdev client as to be rewritten completly, 
it's not a minor change.

What was the proposition for change for RebDev? If it would be upon 
me, I would accept SQLIte as small, robust RDBMS for R3, via plugin 
(to stay external). Wait, we don't have plugins :-)

Steeve, check your private messages.

Steeve, there isn't much code in the RebDev client, by design it 
wouldn't be much work to completely rewrite it. Everything at that 
scale is a minor change - that is the nature of the scale.

In any case, we can do this later.

Steeve: there are opinions, and there are facts. It is a fact that 
you can't be faster / more efficient than the OS. It is your opinion 
that you want to be less efficient.

Gabriele, you're out of my point, i don't say it can be faster than 
the OS.

Today I read acrticle about DB  market. There are going to be some 
specialised DBs in future, and the needs diversify and scenario usages 
too. E.g. IBM has SolidDB in-memory DB, which uses async syncrhonisation 
to DB2 or Informix or something like that ...

Yes it's cool, it's something i try to do with Virtual blocks (blocks 
which are synchronised with files). it"s a tiny scheme (script size 
less than 5 kb).
It doesn't allow sorted blocks currently but it could be.

I am also sure DB's will specialise and already do (couchDB, bigtable..), 
and I plan to make few simple specialised storages to for some my 
projects.

Steeve, exactly as I said, it is your opinion that you don't want 
to be efficient. It is my opinion that I want most of the time.

We have not the same defintion of efficience. 

The efficience of an application is a grid which contains several 
criteria. 

When you choose an implementation. All these criteria can't  have 
the best value together

Hiding this complexity by saying i'm efficient, and you are not, 
without saying you choose to lower some criteria, only reveals one 
thing, you're pretentious.

Can anyone give a range of time where rebol 3 will be released? If 
not, can I just be notified by email when it is?? I'm sick of logging 
onto rebol.com and checking the blogs. I've been doing this for at 
least a year and I'm sick of it.

sick of it

  seems a bit extreme.... there are other good reasons to check in 
  here.


But that aside, how about simply setting up an RSS feded off Carl's 
blog, and set it to pull once a month or so?

Feed.

Nicolas, what?  don't  you come here for abuse when you try to contribute?

Nicolas - your message is a little bit hars, so here's answer you 
deserve - don't come back until 2010 :-)

I personally take visiting blogs as a good sport, and am always glad 
that there is another blog posted, another piece of info available. 
You now have "what's next" kind of summary on rebol.com available, 
so how can you be sick of something, which CLEARLY states facts?

... I can understand, that you might be upset because you can't probably 
touch R3 yet. But that will change rather soon enough too. But even 
then - it is still going to be unfinished alpha, so if you plan R3 
level of functionality with all protocols, etc., you will not get 
it. OTOH you might get some new things .... R3 is product under development, 
and that is what we should remember.

Nicolas, the best you can do is just wait a few months and see what 
happens.

If I understand the last blog correctly, we can expect public version 
of R3 soon: "If you do not have R3, watch the website over the next 
day or so."

yes... that's what we normally translate into "the next 2 months 
or so" :-)

I know of a killer app for REBOLers. A few lines really: one BIG 
RED BUTTON that launches on startup of your PC and turns GREEN the 
day R3 is released.

I think I know what is wrong: Carl is thinking near the speed of 
light, thus time slows down for him, so while it takes two months 
to get the next R3 release to the public, it only takes a day for 
him. :-)

LOL

Steeve: again, that is your opinion here. The OS will always be more 
efficient at handling syncronization between memory and file, be 
it a swap file, or using mmap() and so on. So if your reason is "saving 
memory", then you are wrong here, because any real OS will do better 
than you. Then of course there's Windows, but that's a different 
story...

Okay, I get abuse, a good answer - "check again in 2 months", and 
banter. Pekr, "soon enough"? - what does that mean? and when I get 
it, it'll be an alpha? Now, I don't want to agravate anyone. But 
I'm tired of having absolutely no idea when rebol 3 will be out, 
and out of beta. An acceptable answer to me would be something like 
6 months give or take a year. If that kind of assurance can't be 
given then I'd like a bit of honesty. It's nice to be able to plan 
things.

I guess I'm just angry at myself for having waited this long, this 
eagerly.

Nicolas - every sane person should be able to read between the lines, 
no? So I tell you that all you can get for now is alpha, and you 
ask, if it is going to be an alpha? Waht if NOONE really knows, when 
we will be in beta stage? There were various propositions, and mine 
proposition was to create 3.0 with fixed featureset, and then go 
with 3.1 and later, adding other stuff. I can e.g. imagine 3.0 beta/full 
release just with GUI and R2 level featureset, plus Unicode, which 
is in there. Later can come things like plug-ins, threading, etc.

It's hard to plan at the alpha stage, especially since R3 is not 
at feature freeze at this moment. I use REBOL full-time here, and 
I won't be using R3 in my own projects for another year or so. It 
would be crazy to start doing that now for me. For new users, it's 
a matter of waiting. There is simply nothing else to do.

R3 development effort takes much longer, then we all initially wished 
for. But - in the end, it will pay of. What we should now concentrate 
upon and be grateful of is, that we can be involved in the development 
process, offer our ideas, influence final desing. Carl is exchanging 
ideas with the group on daily basis.