AltME groups: search

So, I need to mock up a webpage to do the same post

and check it out in a browser

I don't have a https server I can test ...

Be sure to use the latest Cheyenne beta (0.9.15). It fixes a regression 
bug on multipart data decoding.

Do you have a log of which files are changed?

Sorry, no diff file list. You can update just the files having a 
more recent timestamp.

So, I guess this means it's a Rebol https problem :(

Wasn't Gabriele asking for people to test a new http(s) protocol 
??

Does the current version of Cheyenne encap?  I tried and I get a 
windows exception when I run the encapped version.

Because, the interfacing with PHP is still under development and 
lacks full path resolution in mod-fastcgi. Remember, that the PHP 
support is not a production-level feature, it's in alpha stage !

it was a typo. Yes, it is 9999 port

modules [
;	userdir
	internal
	static
	action
	fastcgi
	rsp
	ssi
	alias
;	embed
]

globals [
	bind SSI to [.shtml .shtm]
	bind fastcgi to [.php .php3 .php4]
	
	bind-extern CGI to [.cgi .r]
	bind-extern RSP to [.j .rsp]
	
;	user  nobody
;	group nobody

]

default [
	root-dir  %/c/!Docs-private/Xidys/cheyenne-r0914/Cheyenne/www/
	
	default [%index.html %index.rsp %index.php]
	
	on-status-code [
		404	  "/custom404.html"
	]
	
	webapp [
		virtual-root "/testapp"
		root-dir %www/testapp/
		auth "/testapp/login.rsp"
		debug
	]
	
;	"/" [
;		redirect http://softinnov.org
;	]
	
;	extern fastcgi [
;		command	 "php -b $port"
;		pool 	 min 1 max 4
;		server	 127.0.0.1 ; port 1234
;		root-dir "/home/dk/fcgi/"
;	]
] 

;rebol.si.org [
;	root-dir %//dev/si-org/old/
;	default %main.html
;	
;	redirect 301 "/mysql*" "http://si.org/rebol/mysql.shtml"
;	redirect 301 "/rebox*" "http://si.org/rebol/rebox.shtml"
;	redirect 301 "/"	   "http://si.org"
;]

; ###
; To add a new virtual host just duplicate and fill the following
; example host :
;
; my.vhost.com [
;	root-dir %/www/			; documents root directory
;	default [...]			; default files
; ]	
; ###

does something for a long time ... but will probably timeout ...

Testing with Cheyenne 0.9.15 and php, I got a 404 on test.php...

damned, I am dumb .... uh ... wait a min ....

Does your browser timeout on test.php or does it return a 404 ?

try with a telnet localhost 9999 after launching php to see if you 
can connect.

I'll try to setup a working package with Cheyenne and PHP that works 
here (WinXp) and will send it to you.

Pekr, you have an issue with your localhost DNS resolution. You should 
check that your hosts file is not messed up. If you can fix the localhost 
problem, here's a workaround, in Cheyenne archive, edit the mods/mod-fastcgi.r 
file, find the fastcgi://localhost:9999 expression and replace it 
by : fastcgi://127.0.0.1:9999, that should work.

A little update about the work in progress on Cheyenne's new version 
: I'm a little late on schedule (one week), I should release the 
new version tomorrow with several big improvements. The PHP/FastCGI 
final support involves some redesigns of mod-fastcgi that take much 
more time than expected. The good news is that it will result in 
a simple, fast and reliable interfacing with PHP. The other new features 
includes : text localization framework for RSP, support for any CGI 
scripts (including non-REBOL) and a new file upload system using 
temp files on disk (up to 2Gb files supported!). Once PHP support 
will be finished, I'll declare the first 1.0 release candidate (with 
encapped versions released too). I'll write all the docs during this 
debugging phase, so the completed 1.0 should be ready by the end 
of this month. I'm full time of Cheyenne starting from today, so 
it's doable.

No tested, but I don't why this would be a problem for Cheyenne, 
as long as it's a valid HTTP request. There's only two upload encodings 
that Cheyenne currently doesn't support: multipart/mixed and chunked. 
Chunked encoding is only supported in Cheyenne's responses.

I have an embryonic Rest protocol (doesn't work properly yet).  It's 
a reimplementation of http designed more for web services (Rest, 
not soap, though soap if you wish).

Cheyenne new version 0.9.16 is ready. The new FastCGI multiplexed 
support took me some time to debug, but the resulting PHP interfacing 
is now really stable. I just need to update the RSP API doc and run 
a few tests, so the download link will be published here in a couple 
of hours.

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

Changelog :

v0.9.16 - 12/07/2007
	
	o Localization framework added to RSP. API overview :
	
		- #[text] in static parts of RSP pages will be translated.
		

  - new function: say "data" : translate a string! value in the current
		  language.
		  
		- session's new 'lang variable can set the current language.
		
		- new config file options to control default language and 
		  locales resources folder.
		

 o Decode-cgi rewrote from scratch. Cleaner and 2-3 times faster than 
 before.
	

 o RSP request params decoding rewrote. Now GET and POST parameters 
 are unified
	  in request/content.
	  
	o BugFix for encapping %misc/mime-types file.
	

 o File upload support redesigned. Now big files (user defined threshold) 
 are

   directly written to disk in temporary files, instead of being held 
   in memory.

   The temporary files are deleted once the request is completed. So 
   now

   Cheyenne supports files upload up to 2Gb (R2 port! limitation).
	  

 o CGI execution extended to any scripts (not just REBOL). If found, 
 the

   shebang line (#!) is honored (on all platforms). Several perl scripts
	  added in %www/ folder as demo.
	  

 o Module's 'on-started event now fired only once, when multiple HTTPd 
 instances
	  are listening on more than one port.
	  

 o New module : mod-extapp for launching and managing external applications.

   Only the start and shutdown actions are currently supported. Load 
   balancing
	  will be included in future.
	
	o FastCGI protocol reliability improved and some bugs fixed.
	
	o RSP-API documentation updated.

On windows platforms, you'll get the infamous DOS window flashing 
when executing an external CGI ! It's just a matter of 1 flag to 
correctly set in 'call C source code, if you're really annoyed by 
that, ask RT to fix it asap (for 2.7.6 that would be good)! ;-) I 
may reimplement completely call command in REBOL, but it would be 
a big waste of time and energy...it should be a 10 minutes fix for 
RT. Addind a time limit to 'call would be a good thing too, it would 
also avoid me the reimplementation of 'call to add such feature....

No yet, I want a better API and config options than Apache which 
is a real mess ! So, I have a prototype of how it should be a AddHandler 
option should be added, I need to mature that a little more before 
implementing in the next release. Maybe I'll write an article on 
Cheyenne's blog about that to have some feedback....

Firefox offers me download of test.php, instead of executing it? 
Maybe a mime-type incorrectly set?

I recall fixing the DOS box by using a winapi libary call instead.. 
I'll see if I can dig it up.

Opener as a function name? What was I thinking?

For executing external applications as CGI, you need to handle stdin, 
stdout and stderr, that's something that can't be done with ShellExecute(), 
you need to use CreateProcess() for that. I've partially done it 
in my async-call library, but it lacks a few features and it only 
support Windows.

Btw, REBOL provides a native wrapper to ShellExecute, see the 'run 
function.

You need a license key to unlock that feature.

It can't make it work with any binary from the SDK, it looks like 
a bug to me.

Doc: remember the Detective version of async-call also works on linux, 
freebsd, solaris, and mac os x. :) i guess we should make a sync 
version of that for normal human beings to use ;)

detective source should be somewhere on surfnet site... but i probably 
should put a zip on my site too.

Has anyone got a public Cheyenne server running?  With show.cgi available?

This is with the latest beta ...

>> page: read http://127.0.0.1/show.cgi
URL Parse: none none 127.0.0.1 none none show.cgi
Net-log: ["Opening" "tcp" "for" "HTTP"]
connecting to: 127.0.0.1
Net-log: {GET /show.cgi HTTP/1.0
Accept: */*
Connection: close
User-Agent: REBOL View 1.3.2.3.1
Host: 127.0.0.1
}
Net-log: "HTTP/1.1 200 OK"
Net-log: ["low level read of " 2048 "bytes"]
Net-log: ["low level read of " 2048 "bytes"]

== {<HTML><BODY><FONT FACE='ARIAL' SIZE='-1'><a href="/">Back</a><br><br>
<B>Script path :</B> /E/cheyenne916/Cheyenne/www/ <BR><BR...

>> page: read/custom http://127.0.0.1/show.cgireduce ['post join 
"content=" url-encode content ]
URL Parse: none none 127.0.0.1 none none show.cgi
Net-log: ["Opening" "tcp" "for" "HTTP"]
connecting to: 127.0.0.1
Net-log: {POST /show.cgi HTTP/1.0
Accept: */*
Connection: close
User-Agent: REBOL View 1.3.2.3.1
Host: 127.0.0.1
Referer: http://127.0.0.1/show.cgi
Content-Type: application/x-www-form-urlencoded
Content-Length: 147479
}
Net-log: none

** User Error: Error.  Target url: http://127.0.0.1/show.cgicould 
not be retrieved.  Server response: none

** Near: page: read/custom http://127.0.0.1/show.cgireduce ['post 
join "content=" url-encode content]
>>

There's a magic number here 

 page: read/custom http://127.0.0.1/show.cgireduce ['post join "content=" 
 copy/part url-encode content 65528 ]
works
but 

 page: read/custom http://127.0.0.1/show.cgireduce ['post join "content=" 
 copy/part url-encode content 65529 ]
fails

I've planned to make the next release in a few days, mainly bugfixes 
and minor new features. If you can't wait, I can send you a quick 
fix now ?

Does your RSP script use my MySQL driver ? I've fixed a bug related 
to that today : http://softinnov.org:8000/curecode/ticket.rsp?id=10031

it's a script that takes a submitted postscript file and returns 
a pdf

Ok, give me a few minutes and I'll send you a fix by email.

and either put a much higher value or replace it by : if false [

It's not a limit, it's a trigger that switch to the file disk mode 
instead of receiving all the POSTed data in memory

It should be controled by a config file option, but I didn't had 
time yet to implement it.

Btw, for debugging your RSP scripts, you can also rely on the 'rsp-log 
function which is a wrapper to 'probe that will output values in 
console instead of the response buffer.

Graham - because it sounds like taking a hammer on a single issue 
...

We all spend tooooooooooooooo much time with these types of bugs...such 
a shame....

Reichart;   In defense of Doc et al, Cheyenne is still a Beta, someone's 
gotta spend the time  :)  might as well be us.   And Vista...XP, 
well it's MS and "good enough is good enough" seems to rule the day 
in Redmond.


And yes it is a shame.  If motorola had won an early lead in the 
chip wars, the 68K flat memory model would have saved an untold millions 
(billions?) of man hours for the PC industry.  If MS hadn't been 
allowed to overhype Chicago (for what, 3 years?) and then FUD  OS/2 
to death, we'd all have object oriented desktops that we could talk 
to by now. But we plug ahead, mostly oblivious.  :)  Sorry, this 
should have been in Vent, so I'll end with

Go Doc Go

Pekr: are you using a php.ini file ? If you're using one, just remove 
it and retry the test.

I got a message from another user having the same symptoms, so now 
at least, I know that it's not your PC fault ;-). Still, I can't 
reproduce it on my development box....

I guess it should not. Currently, what takes me time is the web control 
panel that I'm adding to Cheyenne and the UI part (HTML) really takes 
a lot of time. Once it's ready, I'll release the 1.0 rc1.

is that to replace a console application?

Anyone got a wiki working with Cheyenne ?  Vanilla or derivative?

Ok, the issue with PHP interfacing can be solved by specifying a 
full path for 'root-dir in config file (it's not related to Windows 
version). I'll fix that for the next release so that relative path 
could be used too.

If you don't want to mess with the httpd.cfg file, it's a one-line 
fix, just change the following line in %mods/mod-fastcgi.r :

Doc - currently on vacation with my Vista notebook. That one line 
fixes the problem! Tested under IE 7.0 and FF 2.0! Thanks a lot. 
Now the last thing is to get mySQL into non-installable version :-)

BTW, there's a MySQL version without installer (in ZIP format for 
Windows), see : http://dev.mysql.com/downloads/mysql/5.1.html

Most languages support the CGI interface, they call all be used with 
Cheyenne. I plan a specific support for Java servers (by implementing 
AJP protocol in Cheyenne).

There's a error in RSP-API documentation, several RSP examples refer 
to session/alive? instead of session/active?.

It's been a while.  Go Doc Go  :)

Btw, work on Cheyenne keeps advancing but slower, due to my lack 
of free time, customers have a higher priority...

It's a french expression meaning : someday ...(just kidding) ;-). 
I need a couple of days of work on Cheyenne to reach the rc1, but 
I only have an hour or 2 to work on it, here and there, so it's hard 
to schedule a release date...the customer project I'm leading is 
taking almost all my time.

This is a serious remark - Cheyenne is a killer app and if a lot 
of the rebolers donate someweher between $20-$50 you mighht be able 
to work dedicated on it for some time. The community would get a 
great product....

Graham: it's not about the control panel, it's about several features 
that need to be fixed or added to make a stable and consistent 1.0.

Maarten: thanks for the offering, but I'm not sure that the community 
is big enough for such funding. Anyway, funded or not, I'm going 
to work on it and finish it, a lot of our internal projects depend 
on it. It's just a short delay (a few weeks) before going rc1.

hmm.  running as a service  ... nice nice nice

I'm tried using Firedaemon to run Cheyenne as a windows service but 
noticed aberrant behaviour which I reported above.

Petr: Cheyenne has to be registered as a service before being able 
to start the Cheyenne service.

Graham;  I just installed Vanilla under Cheyenne.  It's working, 
but the lack of docs is making it a pain to  configure.  I'm not 
sure if setting vanilla.options.metadata  "space-mode" "open" is 
the proper way to go about things or not, but keeping it "closed" 
doesn't seem to allow much.  Until I figure out how to get associate 
status on user accounts, my test head is "open" but closed behind 
the firewall.  But it seems to be working, if not a little rough 
around the edges now I'm getting used to MediaWiki.


I think I might brave a kick at turning on PHP with Cheyenne, and 
then see if copies of MediaWiki and phpBB will run.  If so, I might 
start building up a homesite for user.r right here in peoplecards.ca 
land, but not if it means a conversion to Apache to make a wiki and 
a forum work.


Anyone going to tell me not to bother trying MediaWiki or phpBB because 
it won't work?

Good to know vanilla runs under Cheyenne .. it should be a lot faster 
running that way instead of under Apache.

it should be a lot faster running that way instead of under Apache. 
Why?

Nope.  Just a Cheyenne fan.  The patchy server is just fine.  But 
Cheyenne is REBOL  :)

I'm using Hayes Deki as a wiki now.

comes with a REST api

My brain hurts..I'm using Rebol to make my life easier. I do not 
have time to figure out a new wiki or  whatever every other day.. 
Nothing against you smarter guys but Iove rebol because I'm finally 
able to see a problem or need and solve it with a simple rebol app. 
!Cheyenne is my hope for an easy rebol path to the web without Java 
script, php, perl, AJAX etc.

Graham; Think I should persevere with Vanilla?  It is REBOL.  I'm 
questing for a good forum/wiki combo and the search started today, 
so I'll take any and all advice...as long it includes the word Cheyenne 
in it.  :)  I've decided to branch out of all REBOL mode but not 
too far and not at all if possible.  But RBBS is not going to cut 
it for a forum in the long haul.

Btiffin ..now I appologize for interrupting a conversation

have a vanilla running in rsp not cgi, but still need to replace 
the session+logio with cheyenne session+login and I'd also want to 
put snip in a db

I don't think I would have pursued setting up peoplecards.ca without 
a REBOL web server behind it, and now to patiently wait for (or get 
motivated to write) a nice REBOL forum.  :)

As much as I like the idea of Cheyenne i thing the Rebol plugin is 
the future. The adobe and Microsoft solutions seem to bypass HTML. 
 If R3 can offer aht I think it promises why creat an html base site 
if you can make a rebol app and "plug it in"  to the site.

It may be too late, but I've always wondered why there isn't a REBOL 
browser in the offing.  In the beginning, a whole decade ago, which 
is 70 internet years, the Hot Java browser got more press than Oak 
ever did.

Java.  Before Gosling was sitting in a cafe worried about naming 
conflicts.

With R# I would like to some way to atleast display a web page in 
a window/face..

I'm finding that (like most non-trivial REBOL web apps) vanilla is 
using globals that conflict with Cheyenne.  session in the first 
case I've tracked down.  It won't be that hard to fix, but name collisions 
are a pain in the...

Graham;  I was a polyFORTH programmer.  'being updated?'  Why that's 
for young whippersnappers.  :)  Old and stale is way better.

Seems to me that is a problem with Cheyenne CGI.  You mentioned that 
QM has some globals conflict?  Though I understand CGI inclusion 
is for convenience, some compatibility -- not as the recommended 
development path.

'that is a problem' == 'Vanilla is using globals that conflict with 
Cheyenne'

Yeah, QM conflicts with  request  and Vanilla conflicts with  session 
 (at the quick glance I've taken so far).  These types of problems 
are pretty easy to fix given the motivation.  REBOL is eminently 
readable; all it requires is a little motivation, time and judicious 
use of context or global find and replace.  Collisions are always 
hit or miss, but the web related scripts usually collide just by 
nature of the higher level words being the perfect words for the 
concept at hand.   People running Apache would never see these collisions.


R3 holds a lot of promise in allowing us rebols the freedom for independent 
development that others can combine in fun and magical ways, worry 
free of this issue.  Another year and this type of complaint should 
be a thing of distant memory.

Yes, that is my hope.  I've been pining for the namespaces for some 
time (instead of building up a succession of leaky objects).

I wonder if it makes sense to associate globals with a webapp.

Or all the RSP scripts of a single instance.

I'm not sure to understand the issue with Cheyenne CGI ? For RSP, 
there's a list of global words that MUST not be modified like : request, 
session, response... If you want to use, in RSP code, a framework 
that will conflict with RSP words in global space, you'd better wait 
for R3 to cleanly handle those issues, R2 namespace managment is 
just too limited.

not yet but he is working on a new release, probably a good time 
to send in bugs (if any!) and feature requests http://softinnov.org:8000/curecode/

Magic has a more complete framework

I've been using rsp for a few small projects but I do not know its 
full capabiltiy. Yesterday I wrote a counter in two lines of code.

If you haven't, you should at least give it a try, you wont regreat 
! assured! 8-)

Perhaps this is more a chat related issue.  How would you feel if 
you went to a site  index.html  (explicitly .html)  and later found 
out it was actually an rsp  file with an .html filename.   Is that 
dirty-pool in web land?  I'm asking as Cheyenne .rsp makes it so 
easy to keep track of page hits and there are no <script> tags required 
and no redirects etc etc. I haven't turned it on in production peoplecards.ca 
as I think it's dirty-pool.  Looking for other's opinions.

Ok.. i have a rudimentary version of Atom running with Cheyenne.

Anyone considered writing a phpBB in Cheyenne and RSP ?  Something 
that would be capable of hosting 1000s of users