World: r3wp

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

<form action="show.rsp" method="POST" enctype="multipart/form-data">
	<input type="file" name="ufile" size="16" />
	<input type="submit" name="usubmit" value="upload" />
</form>

BTW, file uploads are currently stored in memory only. I'll improve 
that to use the disk instead for big files.

great

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

Just imagine converting these to run Cheyenne .. mini Rebol appliances

Thanks for the link, I plan to play with some small linux and R3 
to see how small it can be.

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.

Petr, Isn't this AddHandler the same as was demonstrated with the 
Demo.r which can be defined in the %httpd.cfg globals section
 bind-extern demo to [.dem]


Add demo.r which in %handlers/  can do anything you like with the 
content?

MikeL - I am not sure I understand what you mean ...

so you think I could do:

bind-extern pekr-rsp to [.html .htm]

and then putting  pekr-rsp.r into %handlers/ ?

No, handlers need to implement "handler's API".

it's not that hard, thought, but currently undocumented.

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

ok, thank you very much. I really think it would be usefull feature, 
as I really don't like RSP aproach ....

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.

Maxim  - I looked into remark and I don't like it either. As I said 
- I will not accept any system, which ruins normal html (template 
viewing) :-)

ruins?

what do you mean?

gfx man has to do his work, and put some tagging into comments blocks 
at max. .html is registered with handler, and goes via my-rsp.r. 
It either does nothing for the page (static one), or parses tags 
and knows what to do with the template. No html plus rebol code mixing, 
no custom tags ....

but we should move to web group probably ...

you just said "or parses tags "  so the .html page HAS code of somesort... 
I don't see your point?

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.

Yes, but you'd want it to be blocking for the end user in this case 
so he sees the completed status. Question is: will that block Cheyenne?

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

With UniServe's async HTTP protocol, it won't block Cheyenne.

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

I see, so the question really is streaming (and proxying the data). 
That 1.0 is gonna be feature-packed ;-)

I'm sure you'll put 1.0 on good stress-tests ;-)

All ;-) aside, any timelines for 1.0 + docs?

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.

Starting from 1st july, I'll be full time on Cheyenne.

cool

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

I'll add Cheyenne and my other projects (MySQL driver, ...) within 
CureCode once I fix all these annoying little bugs we've found yesterday. 
So I'll wait til the next CureCode release, which should happen by 
the end of this week.

In the meantime, you can report bugs here (only the most important), 
keep the rest for CureCode ;-)

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.

Go Doc Go!

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

Tour de France

on steroids?

This is not really about Cheyenne .. but what is the better approach. 
 Using RSP to completely build your page and display it from your 
datasources, or to dynamically construct the page with javascript 
and then feed the data in Ajax like ?

I'm thinking that maybe I should be using RSP to create javascript 
pages that fetch the data using async http ...

my best approach is generate html page as much as you can then load 
dynamic stuff with ajax/js.. you need content for SEO so pulling 
everything with ajax isn't the best approach

..and don't listen to Terry ;-) go with jQuery!

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

But that is the approach I am tending towards