AltME groups: search

What i did with Framewerks is when a client logs in, I generate a 
random hash, and store it as a cookie, as well as on the DB associated 
with that user.

Set the cookie to expire in 10 hours (log in once a day)

On wirting modules, is this how it works: (?)
- create a mod-<name>.r
- start with install HTTPd-extension
- name 'mod-name

- order -> this I don't get but it controls the flow through mezzanines
 the rest is custom code


Q: what other data is available in a mod and what is the order thingy?

I associate the the IP with the user a well.. if the IP is a mismatch, 
the cookie is void

Re: php / fastcgi, didn't had time to work on it this week, but it's 
high priority for my company, we need to put a few php apps onlin 
with Cheyenne, so I'll work on that in the next days.

What's the issue with windows cookies? .. if there's a timezone difference, 
can you not adjust the expiration accordingly?

Although that's a bit nasty.

well, it might just be the demo.. but if you put a url with a slash, 
you get a different result than without the slash.. sometimes

thanks.. I will take a look

(I hate to be nagging but... any answers to my how-to-write-a-module-question?)

In the modules body you have to implement callbacks (HTTPd phases) 
if you want your module to react on requests. The order is just the 
position of your module's callback for a give phase, among the list 
of other modules.

(You should create a macro key for this answer  Doc)

Thanks, I'll be looking into this a bit more.

Doc, you should create a basic hello world module.

How about the listening ports... can you receive a msg on one port, 
and respond on the other?

FTP server, a service that I wanted to add to UniServe since a long 
time...

Ie: I can read a page from my server, and when some particular IP 
reads as well, it can push a message to my page.

mod-router - a module that routes request based on a sitemap

mod-router: you mean being able to translate the request URLs for 
a whole site, based on a sitemap description ?

that could be useful when refactoring a whole web site that is already 
deeply indexed by search bots and want to keep  it's high ranking...

Very cool module, Marteen, I already have a customer where I might 
use it !

I think it should be easy because the trick is to allow a set of 
parse rules for the translation in a sitemap.cfg for this module. 
That way you can utilize parse's full expressiveness :-)

I guess it must be a RSP problem.

it's a simple url-encode and then dehex with characters missing after 
the dehex

Paris, we've found a bug!

url-encode: func [
    {URL-encode a string}
    data "String to encode"
    /local new-data
][
    new-data: make string! ""
    normal-char: charset [
        #"A" - #"Z" #"a" - #"z"
        #"@" #"." #"*" #"-" #"_"
        #"0" - #"9"
    ]
    if not string? data [return new-data]
    forall data [
        append new-data either find normal-char first data [
            first data
        ][

            rejoin ["%" to-string skip tail (to-hex to-integer first data) -2]
        ]
    ]
    new-data
]

I use:
url-encode: func [
    "URL-encode a string" 
    data "String to encode" 
    /local new-data
][
    new-data: make string! "" 
    normal-char: charset [
        #"A" - #"Z" #"a" - #"z" 
        #"@" #"." #"*" #"-" #"_" 
        #"0" - #"9"
    ] 
    if not any [string? data binary? data] [return data] 
    parse/all data [any[
    	  copy tmp some normal-char (insert tail new-data tmp)

     | copy tmp some #" " (insert/dup tail new-data #"+" length? tmp)
    	| copy tmp 1 skip (

      insert tail new-data rejoin ["%" as-string skip tail (to-hex to integer! 
      to char! tmp) -2]
    	)
	]]
    new-data
]

Marteen, about your questions, there's currently several web sites 
running with several months uptime. Cheyenne is quite resistant to 
all classic web attacks (tested with the Nikto package). About speed 
and performances, I've done a few test a year ago but a lot of things 
changed since, so I need to do some new benchmarking (anyone tried 
with Apache's ab tool ?)

Oldes, thanks, I've made a minimal url-encode function (due to lack 
of time). I'll wrote a better one for the next release. Not sure 
what approach is faster, changing the argument series or building 
a new one...will test that.

Marteen: for static 1ko files on a recent hardware, it should be 
around  500+ req/s.

I saw wil reported 200 reqs/sec with an Ajax/DB (mysql) app on a 
dualcore

Wrt session support: nothing stops me (or anyone else) to create 
a db-session lib that you can use from RSPs. The RSP model is inherently 
extensible.

Sure, you can bypass the internal session engine and use your own 
;-). Commercial support on Cheyenne, yes, that's a service we're 
already offering.

Wrt  commercial support: what are the prices and what is the service 
(perhaps better to discuss this privately unless you can make a marketing 
statement ;-)

I don't know how rsp fits into the picture, but once I have something 
of a remark loadable lib working, I'll try to get others to better 
define how to merge rsp and remark (mainly what rsp can add to remark... 
things like session control maybe).  maybe rsp doesn't even become 
relevant... more details to come as I work out all the parts of this 
endeavor.  btw, this effort is brought up by need... not just hobby 
fun.

I also did an html-encode to allow easier form interaction... does 
anyone find a use for that?

that was a message for doc... and sorry if reading it , it sounds 
like an order.. <phew> sooo not intentional...  the download link 
I mean, on the main cheyenne root page... you really should update 
that root page its seems to be like 6 months old now!

Max: glad to see you using Cheyenne too. About the home page, yes, 
it's still the old one, that's intentionnal for a couple more weeks, 
I want to reach a 1.0 beta first before putting the new Cheyenne 
out in the wild (that's why I keep the current releases almost confidential). 
Currently I want to focus on development and documentation, and only 
support a small group of early adopters (that's you guys ;-)).

A precision about modules : modules are executed in Cheyenne's main 
process (same process as UniServe and HTTPd service), so modules 
execution has a direct impact on Cheyenne performances. In order 
to obtain the best performances and best scalability, you should 
implement also what is currentle called in UniServe : a "handler". 
A handler in UniServe's context is a module executed in a background 
process, so it's not blocking Cheyenne's main process. A good approach 
might be to implement a module first, then export some of the most 
CPU intensive work in a external bg handler. That's the way CGI and 
RSP support is implemented. For a good example, see %mod-action.r 
and %handlers/CGI.r

Btw, mod-action provides a general purpose background tasks launcher, 
you could use it for making your first "bg handler". Here's a small 
sample code for implementing a bg task handler called "demo" :

- Add in %httpd.cfg in globals section :

	bind-extern demo to [.dem]

- Add  %handlers/demo.r :

REBOL [
	Title: "DEMO handler"
]

install-module [
	name: 'demo
	
	on-task-received: func [data][	
		data: reduce load data
		wait 0:0:3				; simulates a 3sec long processing
	

  result: reform [		; you have to return the response string in 'result
			<html><body>
				"You're IP is :" data/ip
			</html></body>
		]
	]
]


- Then create a fake %www/test.dem file (with any content, not used 
in this demo handler)

- Launch Cheyenne and try : http://localhost/test.dem

Hey Doc, thanks..
One thing I was trying with Uniserve years ago went like this.. 
1) A http request is received as usual. (port 80)

2) Depending on the request, Uniserve would launch a process that 
may run for hours (ie: reading a website looking for changes), and 
would occasionally send a message back to the ip address, but on 
a different port (communicates to a flash script on the original 
response page, that in turns manipulates the DOM.)


So, what's the best method to run these small scripts as to not block, 
and close without closing the server. 

I still want to serve up an HTML response, so it's a hybrid of sorts.. 
sends back a page AND runs it as a handler too?

UniServe is based on the classic request/response model. You have 
to implement a specific UniServe' service for your specific need 
(like sending a response to another client than the one who sent 
the request). I guess you'll have to maintain in the service's context 
a list of the (browser, flash) connections couples, so there's some 
probabilities that you'll end up write a full custom HTTPd service.

thanks for the info about bg stuff.  right now I will be concentration 
on reformating remark so its a loadable module... a few details make 
it more complex than it could be.  (remark being so flexible).

Doc, I guess my question is, how can I pass a message from a module, 
to a Uniserve service?

uniserve/shared space or a global function.

An application is just a subdirectory right? And it always requires 
a login?

If so, is there a way to bypass the login>

Take a look at testapp/login.rsp.  I think you just need to session/content/login?: 
yes and response/redirect/ "/theapp/" to get round a login form.

always requires a login

 : no, just remove or comment the 'auth "..." part  in config file.

by default, there's no limitation. If you add the 'auth keyword in 
a web-app definition, you need to be logged in before being able 
to access any resource (that's why you get redirected automatically 
to the login page). Even when 'auth mode is on, you can freely serve 
resources from the /your-web-app/public/ folder.

knowing there is some some of admin config control panel module, 
is there a way for that control panel to send commands to other modules 
through a web page served from cheyenne?


for example, remark has a custom tags definition which can be changed 
(static & dynamic) .  if a control panel allowed integration to modules, 
I could use it to tell a remark to reload its tag definitions.


is this possible?  or will I have to create some sort of (secret) 
admin page specifically for remark somehow?

I am asking,  cause I don't want to have to reload the tag defs at 
each page gen, obviously, that's part of the point of building a 
module in the first place...

fyi - in R0914 the example for the set-tray is a bit clearer so you 
can add some of the samples or other actions aside from Quit to the 
set tray (right mouse) menu.

MikeL: good idea, btw, I plan to add a "Reload Config File" option 
soon in this menu.

Re: config control panel: there's some experimental stuff, but it 
still needs a better internal design. If you need to expose some 
parameters, just fill the words: [...] block in your module definition 
and add some config options.  (this is  not yet documented, but by 
looking in mod-static or mod-action, you'll figure out easily how 
to use that feature).

Cheyenne.r does bypass settings in uniserve.r, httpd.r, etc, which 
is a feature! for example if you set verbosity in httpd.r, it will 
be bypassed by code in cheyenne.r which takes in command line parameters, 
look in the source of cheyenne, on the bottom ;-)

Any chance of having the custom 404 a rsp page?

Hi Doc,

I was referring to something like this 
   construct/with
                cgi-block
                   make object! [a: 111 b: 222 c: 3]


from http://www.rebol.org/cgi-bin/cgiwrap/rebol/art-display-article.r?article=x60w#toc-20



It could be added by all users to the results of validate but then 
it would be not be a standard cheyenne solution. It makes sense to 
me it is ''validate.

Thanks for the example. I agree, it's a useful feature. I'll see 
how I can improve 'validate to support that while keeping it  short 
and fast.

I think doc said before that it won't be processed as rsp if using 
a custom 404 handler like this.

A little competition  http://www.server2go-web.de/

Pekr: AddHandler can be implemented now in Cheyenne. Should it work 
like in Apache (binding a handler to a file type) or can we make 
something smarter. Any ideas about that ?

I don't have any ready, but you can easily try by using the show.rsp 
script as the target of a form uploading files.

Doing a simple test doesn't seem to work, there's maybe a regression 
on file uploads handling, give me a few minutes to test that.

To test file uploading, here's a short HTML form (put it in %www/) 
:

http://bytered.com/siteinfo.html- website running on a converted 
LinkSys NSLU storage device.

Doc, as for AddHandler. With Apache, I put following into .htaccess:

AddHandler rsp .html
Action rsp /cgi-bin/rsp.cgi


So above means - take .html and send it as a parameter to rsp.cgi 
... simply it is a reverse aproach from your RSP.

I'll see how to add such feature in a close-to-apache way, just need 
to think about it a little bit more.

next week pekr, you will be addicted to remark mod  :-)  I am working 
on porting the old remark tag API within the new processing kernel. 
 its like a mod within a mod... basically you can add new pseudo 
html tags right in your documents.

What happens when I upload a 300mb file to Cheyenne (hypothetically?)

Currently, you'd better have a lot of RAM ;-). File upload support 
is still quite primitive, I'll improved that for the v1.

I am thinking of an S3 scenario where I want to "pipe" a huge file 
upload to Amazon S3 (as example)

You'll need something like a mod-proxy (to be implemented) to stream 
your upload to another server.

I already have the HTTP protocol with streaming support for UniServe, 
so this shouldn't be a big work to implement such module (would just 
require to think about how to make it as generic as possible).

Blocking for the end user : sure as long as he hasn't upload all 
the file, he won't receive a response from Cheyenne (that's the HTTP 
protocol).

Cheyenne should be feature-completed for 1.0 by the end of the month 
(was delayed by other sub-projects, like CureCode). Docs would need 
at least a couple more weeks to be done, so mid-july seems reachable 
for an official 1.0.

Doc,  Will you add a project to CureCode for Cheyenne or do you prefer 
them here?  (he says as though he found one)

Cheyenne release v0.9.15 beta. Download at http://softinnov.org/tmp/cheyenne-r0915.zip

Changelog :

v0.9.15 - 20/06/2007


 o RConsole was not started by default in the previous release. Fixed
	

 o RSP: 'include function protection from infinite cycles changed. 
 It's

   now based on a counter (5 maximum recursive includes). It's a little 
   less

   cleaner than stack-based tracking but much more reliable (avoids 
   matching
	  paths and targets).
	  

 o HTML.r library rewritten from scratch. Now, faster and more conforming 
 to 

   standards (Full range of Latin1 entities supported). Fixes URL-encode 
   bugs.

	o BugFix for command line parsing in encapped Cheyenne on Linux.
	

 o Fixed an issue with 'decode-multipart in RSP.r. File upload should 
 work ok 
	  again.
	  

 o Added a new global function : 'rsp-log value. Outputs values in 
 console for 
	  debugging RSP scripts. Works as 'probe.
	  

 o Reloading config file now supported. Running sessions and client 
 connections

   survive to the reloading process (needs some additional testing). 
   Activating
	  config file reload is done using:
	  
	  		- (Windows) "Reload Config" menu option in systray icon.
	  		- (UNIX)     kill -s HUP pid
	  		

 o UNIX signals SIGINT,SIGQUIT,SIGTERM now catched to allow cleaner 
 exit and last

   minute actions. Triggers the new 'on-quit event for HTTPd modules.
	

 o HTTPd internal events (not phases) refactored to be cleaner. New 
 module's
	  events added:
	
			- 'on-started:	when Cheyenne starts.
			- 'on-reload:   before a config file reload happens.
			- 'on-reloaded: after a config file reload happens.
			- 'on-quit:     when Cheyenne is about to stop and quit.
			

 o RSP sessions can now be made persistent (can survive to a server 
 complete restart).

   This option is controlled by a new config keyword: 'persist. Usage 
   is :
	  	
	        persist [sessions]    ; other flags can be added at will
	        

 o BugFix in session cookie handling for web-apps using 'auth mode. 
 Now the cookie

   is sent on the 302 redirection to the login page avoiding the creation 
   of a 
	  "shadow session" that will never be used. 
	  

 o FastCGI is under heavy work so mod-fastcgi is commented in config 
 file to avoid

   fastcgi startup. If you want to play with PHP, just uncomment the 
   line.

I'm feeling like running in a marathon ;-)

I don't really need SEO because it's a private portal ...

This is one area QM has sought to resolve.  It's likely it can be 
done with Cheyenne app methods?  Use Hijax -- build an RSP hierarchy:

<template>
  <portion />
</template>


Access %template.rsp when requesting a full page, and %portion.rsp 
when you only want inline content.  Use JS to hijack links to full 
pages and replace them with methods to access and display inline 
content.

I have this odd problem with trying to execute a batch script from 
an rsp page.

I do a call/wait and get a return value of 0, but the script doesn't 
actually do what it's supposed to do .. viz. convert a ps file to 
pdf.
but the same batch file called from a rebol console does work.

and returning a 0, even though it doesn't do what it is supposed 
to do ie. invoke ps2pdf

but the same .cmd file works fine in a rebol console.

I wondered about that.  But then it should hang and popup a security 
requester and it doesn't

I start cheyenne up as a batch file using firedaemon, which turns 
this batch file into a windows service.

So, it appears for the moment I can't use firedaemon to run cheyenne 
as a windows service

anyone got any other ideas on how to run cheyenne as a windows service?

Firedaemon might be running Cheyenne as a different user.

Or, is it because # is not a legal character in a url?

Is there a limit to how much you can send in a Post command?

As you might have read from above, I am attempting to post postscript 
to a RSP script to convert to PDF.
4k of postscript sees the script complete.
But 92Kb of postscript - and I get this response

make object! [
    code: 800
    type: 'user
    id: 'message

    arg1: {Error.  Target url: https://www.compkarori.co.nz:443/cgi-bin/createpdf.rsp 
    could not be retrieved.  Server response: none}
    arg2: none
    arg3: none

    near: [page: read/custom https://www.compkarori.co.nz/cgi-bin/createpdf.rsp
    reduce ['POST join "content=" content]]
    where: none
]

I think a POST should be okay with 100kb of text .. so perhaps there 
is problem with Cheyenne's handling?

Maybe I should try and simulate a multipart form post on the client 
side instead??

Check your httpd.cfg file to see if you find a 'post-max directive.

# is a legal url char... Rebol's decode-url is full of bugs for example 
this url is bad decoded as well: http://test/path/target?text/something

I did a grep on the sources,and I can only find post-max in 2 files 
...

mod-static
post-max: [integer!] in main

httpd.r
limit: select req/cfg 'post-max

I guess I'll just create a limit in httpd.r

So, if you try 


page: read/custom https://www.compkarori.co.nz/show.cgireduce [ 
'post join "content=" content ]  
then this fails if content is a few kbs

but if you do 


page: read/custom http://www.compkarori.co.nz:8100/show.cgi reduce 
[ 'post join "content=" content ]

it works fine.

What a shame.