World: r3wp

It's vital for any software.

In the past, Carl has made a few attempt at OSS, but it seems to 
me, without understanding how it works. I guess that's why he was 
disappointed when View Desktop was opened for all to modify and he 
received no contribution after several months. The issue was not 
with open sourcing it, it was IMO, in the simple fact that (let's 
put it in crude words) : nobody really cares about View Desktop!

He should have tried with IOS ...

Has he OS'd anything else?

I remember the calendar app was broken in IOS and the source was 
hidden. But that got fixed by efhishant

The situation with REBOL language is very different: it's our base 
programming tool, so it's extremely important for us to get it working 
right and keep on improving it. We are also lucky because the % of 
rebolers with good enough C skills and CS understanding is quite 
high for such a small community, so, (getting to the conclusion), 
if R2 was fully open sourced (real OSS, I mean BSD or GPL, not RLA), 
you can bet on it becoming the faster growing project of all times 
in the REBOL world! I think the main issue in that case would be 
to properly organize all the contributions.

Why not open source R3 instead!

Doc, not caring about the Viewtop isn't entirely true. The problem 
is also that all REBOL experts are very busy with other projects. 
 For R2 it could have been an essential script deployment tool for 
end-users, but that's too late now, and ReBrowse is a much better 
idea anyway.

the potential problem with open sourcing r2 is that you lose all 
your r3 developers ...

Open sourcing R3 core wouldn't help anything. Is it because you are 
up in arms over some curecode bugs that haven't been fixed in a couple 
of months? The important parts to have open are already open and 
of course we have people working on those parts. The process that 
R3 is following now is largely correct.

I bear no arms ...

Open sourcing R3 core wouldn't help anything
. I couldn't disagree more.

Just an observation that the developer base shrinks as time progresses 
...and I doubt anything apart from open sourcing r3 will help

well, doc... do you think the curecode bugs would then magically 
be fixed?

Whether anyone is able help with the source is not relevant ...

Graham, I don't agree with that observation. In fact we've gained 
a few people the last year or so.

the open sourcing is requirement for most serious developers ...

Graham, so if that's irrelevant, should it just be open sourced by 
principle?

Why? Do you intend to read the source code and be happy with that? 
What good does it do, if it doesn't reduce the number of bugs, vastly 
improve the design or in other ways lift R3 beyond where it is now?

It's the principle ...

anyway we should move this to advocacy

but Gabriele and Cyphre have been blocked by lack of access to the 
code ... that is a matter of record

James: Latest Cheyenne binary for windows : http://cheyenne-server.org/tmp/cheyenne-rev66.exe

Do you think the curecode bugs would then magically be fixed?

 Do you really think that this is my intent by having it open sourced? 
 It's open source because its the logical way to distribute such applications 
 nowadays, offering to any user full insight and control over the 
 product.

but if you read this page:

http://www.rebol.com/rebol3/architecture.html


giving the user full "control" over the product is not the intent 
with R3. If you want "control", use one of the many variants of Python 
or Ruby. I quote "control", because at the end of the day, "control" 
will remove one of REBOL's greatest strengths in that there are no 
official derivatives of the language, that the user will just have 
to wrestle with.


Insight is another issue, which can be noble enough for educational 
purposes, and for that, the core would likely make a good study.

Open sourcing R3 core wouldn't help anything

 -- that severely underestimates the skillset available in this community

Yes, I'd estimate that a lot of bugs reported would then have patches 
available now

Wow, wrong group.

Totally :)

Back to advocacy, then :)

Switch to Advocacy or Licensing.

Henrik: continuing topic in Advocacy

I used the variable 'captcha in my registration.rsp, and that has 
overwritten the variable in my web apps :(

which uses the Cheyenne captcha ...

I should have added a protect 'capcha to avoid such issues.

I've wrapped all my code into a context ...

so no more issues ...

Is there anyone using Cheyenne with SQLite?

Never tried. You might have issues with concurrent accesses.

What about making SQLite as an Uniserve service?

All SQLite accesses would block the server, so it would be OK by 
making a standalone Uniserve+sqlite combo. Such SQLite  frontend 
exists already (don't remember if it was made in C, Python or Ruby).

Oldes: I am using it

In www.cebelca.biz each user has it's own sqlite database

I did use it once with cheyenne but had issues, not sure it was concurrency 
or driver version and/or osx version or sqlite version

I suspect if you make a uniserve service then requests are serialized

What happens if I call a process that does not return .... eg.  a 
rebol server via a batch command .. is the helper process blocked?

If you use call it using the /WAIT refinement, you'll block the helper 
process.

use call it => call it

thanks

Thanks Doc. I appreciate that executable.