World: r3wp

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

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