World: r3wp

Documentation can be replaced by a well designed GUI.

if you can use it.  I couldn't because of my server setup.. its all 
text based.

The config GUI is supposed to be remotely accessible (using authentication).

and GUIs are a hell of a lot more complicated to maintain than text. 
 change one little thing in the file format and you've got to redesign 
alot of code... this doesn't happen with a file, since its being 
used directly.

It's the burden of the developer to work hard to make life easier 
for users. ;-)

Anyway, I'll try to list and add one or two comment lines for each 
available option in the next release, but I won't spend days writing 
docs for the config file.

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.