World: r3wp

Worked out the other issue.. Flash requires crossdomain.xml file 
to be delivered up by Cheyenne when running Flash that uses xml.Socket 
(like RASH).
Butt it's working well now.. and very cool. 

Works like this.. I run my local copy of Framewerks with embedded 
Cheyenne server, and park the GUI on any server (always accessible, 
single point of bug fixing etc.) for all to use.. currently it's 
here  http://kommonwealth.com/exper/gui.html


Now, it wont work for you 'cuz you're not running framewerks.. but 
if you were..  you could type into the box "codes" and it would open 
the RASH code file, on your desktop, using your favorite text editor. 
  

But wait.. there's more... 

In my local code.txt file i have the following line

PnG "testing" ][bout: {<pre>ok this works</pre>} makeXML ['DISPLAY 
'MSG "testing works here"]]


So when I open another browser, and point it to http://localhost/
testing  that line is fired (more on all this later).. 

Which does two things.. it outputs "ok this woks" to this second 
localhost page .. BUT (and this is the cool part)

it sends the "testing works here" into the panel on the first kommonwealth 
page. 

In other words, Im able to PUSH data to the remote page at ANY TIME.. 
  this will make for the ultimate in portal pages. 

And.. if that's not enough, Im able to pass messages to the DOM via 
javascript to the kommonwealth page as well. 

Allowing things like sliding in panels.. fading div elements moving 
images.. whatever.


So.. remote page can manipulate my computer.. run apps, do any Rebol, 
reboot .. whatever.. and the local desktop can manipulate a remote 
web page.

Finally.

So.. imagine this as a personal server. One on your IPOD, one at 
home, one at work.. all synced up.. where mine is able to communicate 
with yours, and vice-versa.

Add in some S3 for secured persistent data. (Each unit would could 
load in it's entire DB from S3 on boot up and hold in memory, so 
only the core framewerk could ever be lost or stolen... all nicely 
encrypted too


(Framwerks is currently <1 mb all up, including ATOM, Q, Cheyenne, 
AutoIT(macro software), WINAPI and others)

Forget Ruby on Rails.. this is Rebol on Rockets

Nenad, did some more testing.  Encapped Cheyenne/odbc works under 
XP, and Windows 2003 as vmware.  But when I try it on another virtualized 
windows 2003 ? Xen .. it's not returning the correct data from the 
odbc connection.  Bizarre.

My encapped version of Cheyenne is here http://compkarori.no-ip.biz:8090/Synapse_Web_Portal_Server
In do-sql, it has this ...

					][							;-- RT's drivers
						insert port data
						either flat [
							out: make block! 8
							until [if data: pick port 1 [append out data] data]
							out
						][
							attempt [
								tmp: copy port
								rsp-log tmp
								tmp
							]
						]
					]

retyping -- corrupted by Altme.
This is the only change I made to do-sql in handlers/rsp.r

Nenad.. any thoughts on clustering?

One thing I was considering.. rather than paying for expensive servers, 
like amazon EC2,  to host low usage sites, you could run mulitple 
copies of Cheyenne that would sync up.. and maybe an S3 bucket for 
data.. one at home, one at work etc. .. couple these with dynamicDNS 
so in the event one went down, the other(s) could detect that, and 
update the DNS to take over.  Could do some DNS based load balancing 
if necessary.  If you want to get real crazy.. you could share backup 
servers amongst agreeable Cheyenne users...probably wouldn't host 
e-commerce that way, but wikis / publicly available data would be 
fine.

I would like to see RebService integrated into it. Running RS in 
CGI mode but without the overhead of CGI. So, more like a faked CGI.

You can already run RS in CGI mode (without overhead) with Cheyenne.

Clustering: yes, a lot of thoughts, but first, I'm focusing on releasing 
a v1.0.

Will database backed session mgt make it in 1.0? And integrated mysql:// 
just because it is such a cool driver?

Database backed session: no, need some work on the internal framework 
to make it easier to implement.

What's the need for such a feature ?

Modified the DynDNS.r code to work with Cheyenne.. uses myip.dk to 
determine ip address rather than crawling the router.

A Cheyenne users dynamic DNS server would be handy.

Database backed session: linear scalaibility ina load balanced environment. 
Load balancer doesn't need sticky sessions

Terry;  I like what you have been saying.   You need some supporters. 
  Go Terry Go!  REBOL on Rockets sounds good.  If you get into conflict 
with RoR, you might try REBOL Rays.  Skip rockets, go for a lightspeed 
connotation.  ;)


Again, I like the idea.  The entire framework payload; base language, 
server, funky DB and kitchen sink would fit on a pinhead.  R EBOL 
A TOM C heyenne K itchen-sink.

Go Doc Go!

Yeah, it's tiny  everything is < 1mb including the R&D junk.

Maarten: it just seems to me that a database backend may be overkill 
to store session data, a Uniserve-powered simple server with an in-memory 
hashtable would be way more efficient ;-).

Where is the latest unofficial patched release of Cheyenne/Uniserve 
? I'll see if I understand the code and can help a bit.

Framewerks stores session data in the DB, cuz what's a webserver 
without a db?

here http://softinnov.org/tmp/cheyenne-r0916.zip?

My Amazon public key as encrypted 'n stored by Framewerks
1>���l�TBa�^bOy��Ǩ�%�����6��
��x~���MV

Let me know if you can crack it, then  I'll give you my private key 
:p

http://www.cheyennemusic.com/

Hey Doc, the following seems to be missing from the latest release... 
what's the method to switching on PHP now?

http://softinnov.org/cheyenne/blog.cgi?view=0011

Also, is there still the limit to 4 or 5 consecutive users??

the 0916 version with PHP is working fine... but copying the .. 

	if-loaded? mod-extapp [
		extern-app [
			name	 php-fcgi

.... 
doesn't work?

I spoke too soon.. 

the 0916 version running PHP on windows allows you to read the test.php 
page once.. then each subsequent refresh comes back with a "No input 
file specified." error.

ok.. .spoke too soon again.. the fix was mentioned earlier
path: form to-local-file get-modes req/in/file 'full-path

Interesting how PHP builds any SQLite DBs in Cheyenne's www folder 
by default

Doc, your website is currently down.

working for me

I have same problem, but only with virtual-root. For normal php the 
fix above is working

Everyone using Cheyenne, please go here http://softinnov.org:8000/curecode/ 
and post your bugs or feature requests

Hey Nenad, how does the following work?

;	extern fastcgi [
;		command	 "php -b $port"
;		pool 	 min 1 max 4
;		server	 192.168.0.100 ; port 1234
;		root-dir "/home/dk/fcgi/"
;	]
]

Quick question in lieu of RTFM - how do I get post data as either 
string or binary in CGI mode?

look at the request object

Global 'request is a view  function -- QM has it's own request object...

<HTML>
<HEAD>
	<TITLE>RSP Test Page</TITLE>
</HEAD>
<BODY bgcolor="white">
<a href="/">Back</a><br><br>
<FONT FACE="Arial" SIZE='-1'>
<B>Timestamp: </B><%=now %>
<BR><BR>
<H4>Request parameters :</H4>
<UL>
	<LI><B>HTTP Method: </B> <%=mold request/method%></LI>
	<LI><B>HTTP Port: </B> <%=mold request/server-port%></LI>
	<LI><B>Client IP address: </B> <%=mold request/client-ip%></LI>
</UL>
<H4>Request headers :</H4>
<UL><%
	foreach [name value] request/headers [
		print [<LI><B> name ":"</B> mold value </LI>]
	]
%></UL>
<H4>Request variables :</H4>
<UL><%
	either empty? request/content [
		print "<LI>No variable passed</LI>"
	][
		foreach [name value] request/content [
			print [<LI><B> name ":"</B> mold value </LI>]
		]
	]
%></UL>
<H4>Session :</H4>
<%either session/content [%>
<UL>
	<LI><B>SID: </B> <%=session/id%></LI><%
		either empty? session/content [
			print "<LI>No session variables</LI>"
		][
			foreach [name value] session/content [
				print [<LI><B> name ":"</B> mold value </LI>]
			]
		]
%></UL>
<%][%>
	<UL><LI>No session</LI></UL>
<%]%>

</FONT>
</BODY>
</HTML>

Chris: use 'input word to retrieve POST data.

Graham: the API in CGI differs from the RSP API. When Cheyenne's 
CGI handler is invoked, it tries to mimic the way classic CGI scripts 
are handled by REBOL.

The current Cheyenne version redefines 'read-io in the CGI handler. 
This wasn't a good thing, so the next release will add, instead, 
a new function 'cgi-read-io that have to be used as replacement to 
'read-io.

Terry: for defining a FastCGI app in Cheyenne, take a look here (PHP 
example) : http://softinnov.org/cheyenne/blog.cgi?view=0011

I'll release a new Cheyenne version next week, probably on Monday. 
It will be v0.9.17, not yet rc1, still a lot of details  to add or 
polish for a v1. I'd like also to finish a working version of the 
control panel for the rc1.

softinnov server went offline?

seems down ...

Softinnov.org is down for maintenance (disk crashed), it should be 
back online tonight.

Anyway, I'm still doing some testing/bugfixing for the new release, 
it should be ready a few hours after the server will be back.

Good to know it wasn't Cheyenne that crashed :)