World: r3wp

if the config GUI is web based... then it relies on the server actually 
working...  but I'm not trying to argue with you, just pointing out 
the fact that server configuration is usually much better handled 
in text and I think many admins prefer it.  the fact that everything 
in windows is GUI based is the most annoying aspect about it.

Well, I always thought that GUI was an improvement other text files. 
Cheyenne is suppose to work out of the box with a default config 
file. The admin web UI would be reacheable with http://server-ip/admin/
(just an example).

I have a generic configuration managing library... the documentation 
is directly embeded in the configuration engine... if you save out 
the config or print it on screen, you have all the docs right there 
with it.  if you build a gui which uses the configuration data, you 
can also pull out the text from it. 


maybe that is what should be done.... allow string types within the 
config dialect (and store it appropriately).  then you/we could easily 
build tools using that info directly.

for myself... I would automatically turn off web-based config.  if 
not only for security reasons.

Embedding docs that can be extracted for a GUI is a good idea.

I also have big concerns about security, such a remote admin app 
would be obviously strongly secured.

this being said, I understand the appeal for GUI-based configs, but 
most power users are much more effective with raw data than having 
to fiddle with a screen hiding the data.

screen hiding the data

 you're already supposing that the admin GUI will be badly designed...I'm 
 not talking about doing a Webmin clone (this is the typical example 
 of *bad* UI design, IMHO).

Design is subjective in ALL cases.   what is perfect for one context 
is insane in another.

True, but the goal is to make it simple and easy to use for the average 
user, without requiring to read lengthly docs.

as long as the config GUI is only a tool over the files, and it doesn't 
overwrite the files automatically, I won't complain  :-)

Well, you'll have an option for turning it off, if you really prefer 
to type instead of clicking. ;-)

the format can become more stuctured too, if it makes it easier to 
load back in... but please don't loose the files themselves.

hehe  ;-)

Both approaches can live together. I want the config file to keep 
the same current format even if overwritten by the UI. Most users 
won't even care about the config file anymore once the UI will be 
available.

In fact, I even thought about making a lynx-compliant admin UI for 
text-only users. ;-)

as a point of fact, it is very possible that some modules (like remark) 
will require stuff to be setup which is hard to simulate through 
a gui.  managing a system of nested parameters and list is very complex 
to handle programatically.

Right, that's something Cheyenne's config file also doesn't handle 
(yet).

I'm adding words which are commands within remarks' module using 
the do variant of config definition...  this allows me to grow a 
config by calling the same command multiple times.... this would 
be very unweildy to implement any other way (but not impossible)...


maybe a function-based api could allow us to "hook" into the GUI 
but its pretty hard to cover all possibilities in any case... anhow... 
back to modulating remark.

There's a builtin "process" function in config DO blocks allowing 
to process nested blocks (see mod-static/if-loaded? definition).

It's not as powerful as it could be, thought.

ahh so that launches a new parse config on the block we give it?

Yep

when the config do is performed, I noticed you do a bind on the block... 
the thing I wonder is to what it is bound... its not obvious to me

It binds to the conf-parser object, because it needs (at least) to 
access the process function located in conf-parser.

k thx

Maxim, I tried with the port and it worked..thanks alot, but I could 
have sworn I had tried it like that too...

happy I was of help :-)

It should have worked even without the port number. It's a bug that 
will be fixed in next release.

Any reason why cheyenne does not allow a .r file to be read via http? 
It seemed to work with apache. I had to change it to a .txt file 
to get it to work..after batting my head for many minutes.

in the http.cfg file its assigned as a cgi script:

bind-extern CGI to [.cgi .r]

and the CGI handler will execute it.

you can change this obviously.  :-)

Thanks. I thought it might have something to do with RSP but I see 
it is even simpler than that...

It would be nice to have Cheyenne support UTF8, I have it working 
here with some functions provided by Oldes, utf8/length? utf8/trim 
but a proper html entity converter is still missing, I think Gabriele 
has it but that's on hold by Reichart.. 8)

of note, it's not "Reichart" that's holding it. it's just that Qtask 
the company has not decided on the license yet.

thanks for correcting me 8)

btw, has Cheyenne been considered for Qtask? if not why?

because they use PHP I'm guessing

Cheyenne does PHP, but indeed, the Qtask frontends don't seem to 
use REBOL

Cheyenne has been considered within Qtask, and tested in a test project, 
with success. The lack of server-side SSL is a deal-breaker for the 
main site but it is usable for supplementary services. RSP went over 
well too, so Maarten is updating the original RSP for use in Qtask 
(though not with Cheyenne).

because they use PHP I'm guessing

 - the promotional web site uses some PHP, but the main site is all 
 REBOL.

the Qtask frontends don't seem to use REBOL

 - You are correct, the frontends use Javascript, generating the usual 
 HTML and CSS. That Javascript is often generated using REBOL. Frontends 
 in REBOL are possible though.

Third party tools can be used to tunnel SSL, like stunnel or nginx. 
About RSP, does Cheyenne's RSP miss some features required by Qtask?

True about the tunneling tools, but I'm not the server guy so I don't 
know why they are still using Apache for the main site. I know they 
aren't married to it since the site isn't built on unique Apache 
modules, and because they mention looking at other servers. It wouuld 
depend on performance and scalability, so an alternate soltion would 
need to outperform and outscale Apache and FastCGI. As for the RSP 
features Maarten is adding, don't know what they are yet - it's on 
my todo list to compare the two RSPs to determine if there are features 
that the other could use.

Looks interesting, I hope you'll be able to publish here your conclusions. 
In theory, Apache+FastCGI should be faster than Cheyenne, but the 
application framework used in the FastCGI server, if not deeply optimized, 
might be a bottleneck.

btw, Dock, correct me if I'm wrong, it should be pretty easy to modify 
Cheyenne to distribute task-handlers (RSP processors) on computer 
nodes

Well, there's just a local dependency on config file to remove first 
(in my todo list) to allow remote worker process (for RSP, CGI,...). 
But you need a also a remote process manager to handle the launching 
of worker processes. Anyway, I think that using a front load balancer 
(supporting session affinity) with several servers is a simple and 
efficient solution.

What are the requirements to get a connection to a mysql database?

I have a %httpd.cfg as below   


--------------------------httpd.cfg --------------------------------

globals [  ...  worker-libs [  ...  %path/to/mysql-driver/mysql-protocol.r 
  ...  ]  ...  ]

my.virtual.host [   ....    databases [ db-name   mysql://root:[lpass-:-127-:-0-:-0-:-1]/table]	 
....   ]

----------------------------------------------------------------------


As far as I can see from the documentation and sample files, I should 
now be able to use SEND-SQL a alike on DB-NAME, but that gives nothing 
but script errors

	** Script Error : db-name has no value 
	** Where: rsp-script 
	** Near:  [print mold db-name  


I've already spent hours on this without getting a clue on what to 
do.

Of course I can connect to the database directly thru mysql-protocol, 
I just don't get it up and running with cheyenne.

Ok, I think I've might be up to something here ;-)