World: r3wp

that static form for localised strings is a great idea #[...] 


does localisation effect performance much? I suppose it increases 
RAM usage since app holds the two hashtables in memory (which is 
needed I know for speed)

the #[..] is awesome idea. I have tons of javascript that would otherwise 
become an ugly mix of javascript and rebol

I don't recall anyone using the localization framework besides me 
and now you. :-) This framework is still experimental, it might be 
not suitable for a big application as it relies on a single namespace 
(using same words in differents pages will give you the same translation, 
this is not always desirable).

I'm not aware of issues wrt 'set-default-lang, but I must admit that 
I've never used it, I just switch the languages in my browser for 
testing.

Please add a ticket for that issue at http://curecode.org/si/view-tickets.rsp.

I agree that #[...] really makes things easier and cleaner. Performance 
impact is not significant, the overhead is just a string! PICK in 
a block with a static index as argument (that's one of the nice advantage 
of compiling RSP scripts). OTOH, the SAY function has to do a hash 
table lookup to get the right index (so a tiny little bit slower 
than the literal form).

Good. I have a lot of javascript so #[] really saved my day. I had 
started with >element.innerHTML = "<%= say "some text" %>" and element.innerHTML 
= "#[some text]" is 10x better :)

I will add a ticket, I need to use this function because I basically 
set language globaly for english / slovene version (not based on 
user preferences or anything, it's also different website).

Some texts (that are part of application) are a little longer. I 
was thinking of replacing all of them with "tags", like "add_now" 
instead of "Add now" and "warning_text" instead of "bla bla ........................" 
and having the default language as this tag language from which it 
is then translated to english, slovene, etc.. anyone has any thoughts 
about this?


I could also make a tool that would statically replace all the values 
in say "..." and #[...] if I decide to do so at one time. That's 
why I would preferr the same system for most of things.


I will probably have a separate files where the whole page is text 
, like the instructions.

Looks like a good idea to dig.

cheyenne does support mysql only? or can we use sqlite or sql server 
thru odbc?

you can use anything rebol can use. I am using sqlite also for example 
somewhere.

I have a webapp that uses captcha as part of the authentication. 
 But I need also to allow scripts in ... and so I had to disable 
the captcha.  Any other solutions?

I got the SVN version. How to proceed?

a) how can I get the SVN version to run on my server?
b) how can I create an encapped version of it?

do %cheyenne.r

there's an encap script that comes with the distro

Do I need to configure any paths to get it up & running without encapping?

AFAIR no unless you are using a webapp

is there any other configuration or something to use databases with 
cheyenne? I configured as it shown in web site but I always get the 
error:

##RSP Script Error: 
	URL  = /
	File = www/index.rsp
	** Access Error : Invalid port spec: odbc://test2
	** Where: do-sql 
	** Near:  [do-sql 'test2 "select * from table" 
__txt 62
] 

my rsp site is:
<%
	print do-sql 'test1 "select top 10 * from sec_log1"
%>

and the httpd.conf file:

databases [
	test1	mysql://[root-:-localhost]/test
	test2	odbc://test
]

typo, it should be: print do-sql 'test2 "select top 10 * from sec_log1"

In order to use the mysql protocol, you have to include it as a worker-lib, 
I guess.

Add %path/to/mysql-protocol.r to your WORKER-LIBS block in the %httpd.cfg, 
that should do the trick.

Endo, does opening the database directly from console work?
>> db: open odbc://test2


Also, check what REBOL kernel Cheyenne is running on, if you're using 
one of Cheyenne's binary releases, you won't have ODBC support (requires 
encapping with encmd).

I tried it with mysql also, but the result was same. So it is not 
an odbc issue I guess.

I'm using cheyenne-r40.exe on windows xp pro.

mysql.exe command-line works well.

I tried with cheyenne-r0919.exe binary version with mysql server 
on localhost, same error: 
** Access Error : Invalid port spec: mysql://[root-:-localhost]/test

cheyenne-r40.exe doesn't have ODBC driver.

Can you connect from REBOL console using : 
>> db: open mysql://[root-:-localhost]/test

??

db: open mysql://[root-:-localhost]/test gives same error on console, 
I'm using R2/View 2.7.7.3.1

mysql driver is not already in cheyenne?

no, you must download it here: http://softinnov.org/rebol/mysql.shtml

I think it should be

then how cheyenne load it?

See ChristianE explanations above.

Oldes: I agree, given how often it is used in combination with Cheyenne/RSP.

Hmm.. p: open odbc://test works on console

But cheyenne-r0919.exe still gives ** Access Error : Invalid port 
spec: odbc://test

Don't use odbc - Cheyenne doesn't support it with the default build. 
Use the standalone mysql protocol linked above.

Or if you have the SDK, encap your own binary.

I see. I don't have SDK. Is there a license issue about mysql/odbc 
drivers or do you have a plan to put in next releases?

Don't mix the ODBC- with the mySQL-driver. Doc's mySQL-protocol works 
with all versions of Rebol(2). You use it thru the mysql://-scheme.

ODBC drivers are binary, and are only included if you have /Command 
or the SDK. Which also include a mysql driver, but not as good a 
driver as the free one linked above.

It would be great if the drivers (mysql/sqlite/odbc/postgre) included 
in cheyenne. Ofcourse external dependencies is not good for Cheyenne, 
but optional driver-included binaries would be good anyway.

Well, that's a good idea, but the SDK license is quite restrictive, 
I shouldn't distribute Cheyenne in binary form (see "REBOL API Restriction" 
part at http://www.rebol.com/docs/sdk/sdkintro.html). RT didn't asked 
me to pay any additional license so far, so I don't want to push 
it further by giving away a free /Command with Cheyenne.

Does anybody use user and group directive in httpd.cfg? When I uncoment 
it and use own user name, than I got error:
## Error in [conf-parser] : Error in conf file at:
user oldes
group oldes

Hm.. probably needs mod-userdir enabled... but then it crashes completely:/

ech.. found reason -  now the logger does not have rights to write... 
so it could be fixed

Is anyone running cheyenne, the source code version on linux, with 
the need of /Library (like sqlite / pdf / ... binding) and need to 
setup set-net (for sending email)? If, how are you running it, with 
what version of rebol and how?

Unfortunately I don't think it's possible. At least if you can't 
use /View version or don't have SDK license for Linux (needed for 
Rebol/pro).

Ask Carl to remove the library restriction.