World: r3wp

Ok, so I will try the newest release. Is there a Linux binary already 
available? Or do you all use the source-code version?

How can I find out what version of Cheyenne I'm running?

>> p: open http://softinnov.org
>> p/locals/headers/server
== "Cheyenne/0.9.19"

About your issue, your log shows that the RSP helper process has 
probably lost connection with the main process. It might be caused 
by the IE POST bug.

No binary yet available for the beta 0.9.20

I'm working on it currently, I need a linux binary too for testing, 
I'll publish the link here so you can test it too.

Ok, great. Any time frame ;-)? Or can I use the source-code version 
so long? If, is there a link to dowload it?

Should be available today.

Latest development version 0.9.20 for linux : http://cheyenne-server.org/tmp/cheyenne0920.gz

Robert: let me know if it fixes your stability issue.

Thank you! 8-)

It's just a intermediate binary, it's not the full 0.9.20 version 
I'm planning to release, there's still a lot of small fixes and enhancements 
to add.

I'll give it a try. Thanks.

Ok, up & running. Let's see what happens.

amacleod: did you get vhosts working? I am getting similar reaction. 
 works fine without vhosts... then its lost if the domain matches 
a vhost definition.

aaaahhhh you must include the port number in the vhost domain...

mysite.com:83 [
	root-dir %/www/mysite/		; documents root directory
	default [%index.html %index.rsp %index.php]			; default files
]

if that is how it is being called from the browser.

ex:    http://mysite.com:83/

doc: might I do a RFE (request for enhancement)?


add a ./conf/  dir to cheyenne and load every file that ends with 
.cfg


this would allow us to distribute a configuration file with a module 
and provide setups per mod... its much more flexible to manage.

we could also have a setup for each vhost in our system, if that 
makes sense for the web admin.

even better, add a conf-dir  item which is only available within 
 %httpd.cfg telling cheyenne where to load additional configurations.

conf-dir %conf/
conf-dir [%sites/ mods/]

Sounds useful, adding your RFE to my todo list.

cool.  and I'm reiterating the need to provide a sample file ala 
apache with a paragraph of comments or two which explain all configs... 
just in case you forgot to note it... this for me is big hassle.


for example... the subtleties behind 'BIND  and 'BIND-EXTERN  are 
not obvious to deduce just by the name... 
-what is the difference in how they are cached? 

-is an external handler explicitely needed with 'BIND-EXTERN   (no, 
in fact,  but it enables it)
-how does one use an external handler?

-in what module is the config defined

BIND associates one or more file extensions to a Cheyenne internal 
mod.

BIND-EXTERN associates on or more file extensions to a background 
handler (worker process through task-master service).

The handler name declare in BIND or BIND-EXTERN have to match a mod 
ID or a background handler name.
Examples:

 bind SSI to .shtml => processed by mod-ssi.r (SSI is used as a matching 
 key in the mod)

 bind-extern CGI to .cgi => processed by mod-action.r (bind-extern's 
 dispatcher), then by CGI.r external handler in a worker process.

declare => declared

yes... I already new... but I had to trace the code and lost some 
time wondering why my page wasn't being re-rendered when I first 
used 'BIND  ;-)

I also had to trace the logic to make sure that cheyenne wasn't actually 
expecting an external handler if I used 'BIND-EXTERN...


I ended up loosing more than an hour to figure it out myself... now 
that is just one config... there are MANY... a lot of them I don't 
even know exist.


the above is exactly the kind of information which should be included 
within the httpd.cfg file, even if an example is commented out, but 
provided as an example use.  just like apache does it.

thanks for the help anyways (confirming what I had deduced)... hehe.

I am trying to make mod-remark as consistent and integrated as possible 
with the rest of cheyenne.  the end goal being that you remove the 
rsp from your modules and drop-in remark instead.

I've scrapped the previous remark system in favor building remark 
v3 right away.  this will actually help me build the mod much faster 
and will provide 100% dataflow engine from its first release.  every 
single programmable entity within mod-remark is now based on a plug. 
 the architecture I have now is becoming very orthogonal... instead 
of building up different objects for each level of config, I think 
I'll be able to reduce it to ONE.


these models will serve as references for the !compilator to create 
persistent  !documents... note that !documents are multi-leveled... 
you build documents by linking up document together.... so if only 
part of a !document is dynamic, only that part will cause processing... 
and by dynamic, I don't mean that its cgi... I mean it has actually 
changed.  down to a single HTML element.   that's what I am aiming 
in any case.


!documents can be stored at any level... from server down to specific 
page and single session. caching is embeded in liquid so it should 
be pretty fast, and inter document data sharing should allow us to 
make it very RAM efficient too.

I hate Apache config file. Because I hate having to read tons of 
docs to just "switch on" some app. Cheyenne's config file has never 
been designed to copy the Apache way, nor to be used by average end 
user. It's just a placeholder waiting to be replaced by a builtin 
web GUI allowing a simple, fast and straightforward way to manage 
the server. That has been the plan since the beginning and one of 
the main motivation for building Cheyenne. Unfortunately, I never 
had the required time to complete that goal yet, so I'm stuck with 
that, and that's also why Cheyenne is still at 0.9.x.

but the cfg file becomes documentation... that is the real use of 
the text, and it lives directly within system, so you don't have 
to maintain different things.


hate apache as you like, anyone can configure it very quickly, since 
its all there.

;-)

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  :-)