AltME groups: search

Scala has a lot to offer, especially for server-side. It compares 
very well with others, its main issue is just that it's not REBOL...so 
not easy to wrap a REBOL-addicted mind to it. Besides that, it is 
very promising.

Not to say that a Scala-made web server written by Doc wouldn't be 
cool - it should just be called something else.

Mostly development tools and server-side apps.

server-side stuff for huge traffic sites? I thought you were in the 
qtask team

Without R3 being completely open source, in this day and age, is 
soo 1984. And if the 'killer app' is a webserver, and that web server 
doesn't plan on using R3, then it's not much more than a hobby.
But hey, nothing wrong with having a hobby.

I was reluctant to do that before, CureCode wasn't able to run multiple 
instances of itself on the same Cheyenne. Since 0.9.10, it's fixed, 
so I'm in the process of collecting all my current CC instances scattered 
around on multiple servers on the same Cheyenne server.

<and put them> on the same Cheyenne server.

James: Latest Cheyenne binary for windows : http://cheyenne-server.org/tmp/cheyenne-rev66.exe

All SQLite accesses would block the server, so it would be OK by 
making a standalone Uniserve+sqlite combo. Such SQLite  frontend 
exists already (don't remember if it was made in C, Python or Ruby).

What happens if I call a process that does not return .... eg.  a 
rebol server via a batch command .. is the helper process blocked?

http://www.google.com/codesearch/p?hl=en#8-MruDvODLg/trunk/UniServe/libs/html.r&q=url-encodepackage:http://cheyenne-server%5C.googlecode%5C.com&sa=N&cd=2&ct=rc&d=2

(BTW, I'm doing this to move DevBase to the new Linnode server... 
to offload it to a faster location.)

I've not shut it down yet. But, I've been having difficulty connecting 
to that server all day.  It's probably under 10 feet of snow.

It scales very well... as long as it has a web server sitting in 
front of it.

The web server does the serializing and I/O buffering.

Basically, it does not matter where the proc lives, as long as I 
can "redirect" I/O to it from the web server, which does all the 
TCP buffering.

where's the server code ?

The server's input request packet times out.

So, R3 Chat server has been moved to Dallas TX running in Cheyenne 
on a cloud.

--- Note: login initiated

*** RebDev Error: server connection failed, is server down? (server-failed)

POST /cgi-bin/rebdev HTTP/1.0
Accept: */*
Accept-Charset: utf-8
Host: host.rebol.net
User-Agent: REBOL
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 56


[0.4.0 "Graham" password  login]HTTP/1.1 500 Internal error in REBOL 
CGI Proxy
Date: Sun, 14 Feb 2010 02:05:45 GMT
Server: Apache/2.0.53 (Fedora)
Content-Type: text/plain; charset=UTF-8
Via: 1.1 bc7
Connection: close

Cannot connect (3)

SVN revision 72: File uploading improvements (changes might break 
older scripts)


FEAT: File upload management improved, in-memory uploading removed 
for consistency.

FEAT: request/store specifications changed. Now it renames the temp 
file to its original name by default. Use the new /as refinement 
to move the file (see Changelog).

FEAT: New complete example of file uploading (client and server-side) 
in www/ folder.

FEAT: New config keyword: 'incoming-dir <%/path/> to specify a custom 
incoming folder per domain or per webapp.

It looks that FF converts < > chars automatically inside PRE. It 
should be converted on the server side I think.

Right, for both Jim and Graham, 'validate is the way to go : http://cheyenne-server.org/docs/rsp-api.html#def-23

Request parameters are used to transport data from client to server. 
If a parameter is not sent, having 'none seems appropriate. Setting 
them to anything else "by default" will make you loose this important 
information.

From the logs on curecode.org, both emails have been rejected by 
your email SMTP server. It seems like a SMTP issue (not sure yet 
from if it is from the server or client side). Anyway, I've validated 
your CC accounts, so you can log in.

Your SMTP server sends two 220 greetings lines instead of one which 
doesn't comply with RFC2821, so it is rejected by Cheyenne's MTA 
as an error. I'll improve the MTA to accept such protocol deviations.

cheyenne does support mysql only? or can we use sqlite or sql server 
thru odbc?

I tried with cheyenne-r0919.exe binary version with mysql server 
on localhost, same error: 
** Access Error : Invalid port spec: mysql://[root-:-localhost]/test

There is no library support in Linux's version of REBOL/Core. Only 
in the /View version I guess... but that's in most cases not possible 
to use on servers as not many servers are with X server installed 
as well.

I had this setup on one server. You have to play with etc/init.d 
folders .. I currently also don't have it setup that way because 
I had some problems then and one guy showed me some simpler way. 
(but I can't remember it right now, I can ask him tomorrow)

It's not my server .. .I just told them to install ubuntu server 
32 bit

Mine is Server: "Cheyenne/0.9.18"

Upgraded to Server: "Cheyenne/0.9.19" but bug is still present.

Is there a reason for this? The list on most Unix systems and Syllable 
Server is much more comprehensive

Graham: a few links about your question: 

http://en.wikipedia.org/wiki/Transport_Layer_Security#Support_for_name-based_virtual_servers
http://en.wikipedia.org/wiki/Server_Name_Indication

SNI is in stunnel's todo list: http://stunnel.mirt.net/?page=todo_sdf

I use nginx as a frontend server and cheyenne as a backend where 
Cheyenne ca cretate static pages served by nginx... My motto for 
thic combo is: where west meets east as its American-Russian connection:)

The to do list for 2.7.8 mentions fixing the related error message, 
so I suspect Carl has found that this doesn't work when he briefly 
tried to run Cheyenne on his new server

At least it can be tested with X11 running. Then I find that Cheyenne 
searches for the GNU C library in several places, but not in the 
place where Syllable Server has it. Here's a patch to misc/unix.r 
that fixes this for both Syllable and GoboLinux (the new version 
that's currently in development):

Well, I never thought I would be hacking a web server, so this is 
pretty cool, and Cheyenne makes it very easy :-)

what would cause sudden 403 Forbidden errors on certain pages? Everything 
was fine, restarted the server.. 403

I did my own using SSH and a few server-side scripts and tricks.

I can start/restart the server without it requiring to be setup as 
a daemon.

you can use the remote, if the server isn't running ;-)

Has anyone run pmwiki or any of the other php wiki's with Cheyenne?

 Yes, Cheyenne docs wiki is running on pmwiki : http://cheyenne-server.org/wiki

if it's static, then it can work only for the URL you've written, 
so from the server itself, the URL might be invalid

I mean, if you've used something like ws://intranet/app.rsp and ws://intranet 
is not resolved on your server, that's would be the cause of your 
issue

from the server, i cant' get a message to on-message .. but from 
the other client, I can.. only it won't reply.

Terry: just replace ws:// by http:// and test the URL from rebol 
console with a READ (from your server box)

(or from a ws-enabled browser from your server box)

The exact same code is working fine on another server.. move to here 
and *poof*

is there a ws:// protocol implementation for R2? How do I connect 
to a server and use websocket without a browser?

and cheyenne is an embedded web server

See http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/www/ws-apps/ws-test-app.r

As this is running in main process, when

;-- any handler runs, it will block the server, so, you have to keep 
your code

;-- very efficient, it should run in between 1ms and 10ms if you 
want your Cheyenne

;-- server be able to scale to hundreds of concurrent clients. That's 
the cost to

;-- pay for not having multi-threading...Anyway, you can use the 
'do-task function
;-- to run longer code without blocking.

Websocket server code can be run from two places: either in Cheyenne 
main process (allows accessing all clients ports and detecting ports 
open/close events) or in RSP scripts (using 'do-task function from 
a websocket app) when the job takes too much time (like accessing 
a database).

Graham: websocket is just an evolution of the HTTP protocol, it's 
not TCP, you can't contact a SMTP server from a browser directly 
if this is what you have in mind.

AJAX will remain in use I guess, having a permanent connection is 
not always required and makes servers less scalable. Websockets will 
mainly replace all COMET tricks for server-side events.

Doc, you have a mail server inside Cheyenne .. .that's what I want 
to use.

I also use it as a web server

If a pdf is loaded into a browser .. it allows one to post the data 
in an acrobat form ... but if it is loaded into acrobat reader alone, 
then it can post, but it can't understand any html returned by the 
web server

@Graham: you are using web sockets for a wierd job. The shortest 
explanaiton for web socket is: it is the way to trigger an event 
on the client side from the server side via already open tcp (http) 
connection. ofcourse that connection is full duplex, client and server 
both can send a utf8 encoded (currently no binary) string messages 
anytime.

Sure .. just wondering if it's easier to do thru web ports and if 
the server can notify me thru an open port when it succeeds or fails 
rather than me poll the server

well remark allows you to do this on ther server... and you could 
cache it so its just processed once.

To keep Cheyenne on the html5 leading edge, you may want to add a 
"server-sent events" service as well.

It's basically a one way websocket communication... server -> browser 
 . Not sure what the real advantage would be, perhaps less overhead?

My Chrome 5.0.375.99 scores a "no" at Server-Sent Events :(

ws protocol works,
run the chat server (see the post on the forum)
p: open ws://localhost/chat
insert p "hello"
pick p 1
== "hello"
insert p "/nick endo"
pick p 1
== "server: you known as endo"

The Syllable Server manual has an example how to do that on Linux:

http://web.syllable.org/Server/README-SyllableServer.txt

I don't have nginx running ... it's a windows2003 server

Yes, as explained in the above Syllable Server manual

First of all you must add DNS A records to point to your IP adress. 
And then setup your server (Cheyenne, Apache, Nginx..) to resolve 
the full subdomain.domain names.

Not really; it's running a number of sites, including the Syllable 
sites. It has also performed the final distribution build of the 
last Syllable Server release. But it's not published

Endo: I think it's possible to encap the Cheyenne server including 
RSP files, but it would require some hacking the code.

maybe you need this http://cheyenne-server.org/docs/rsp-api.html#def-56

The JS is executed by the browser once the buffer is returned to 
the browser. What I want is a mapped .r file to process the DOM source 
on the server side. I don't see where the JS concern.

Graham: so say your library updates . .you have to update all the 
pages that use the js libraries" . The answer is yes. The html file 
would generally behave as any other html file that is not backed 
up by any server side.

Terry has mentioned nodejs before .. it's an event driven web server 
... nothing to do with web sockets per se

node.js is a v8 javascript interpreter that could be used server-side 
to make tcp server.

So, not only web server but server with persistent connection too, 
like web sockets.

Javascript on the server side isn't a new idea, but V8 is very fast 
and more light without the html dom complexity.
It's all event driven and seems very fun to play with it.

By the way, /tmp/cheyenne.pid contains "none" on my server, so that 
looks like a bug

My system/version/4 on Syllable Server is 4, so something else is 
wrong

I see PID works when starting Cheyenne with View, but I can't do 
that on Syllable Server proper

Sure, but I need Library in Core to have it be meaningful in Syllable 
Server

old .. yeah, but since I haven't had any issues, I don't change the 
server apps

So, I guess no point trying to produce this error since I am using 
an old server build

The EXE doesn't list the Cheyenne version, and I dont think the server-software 
result gives that either, so what's the best way to check?

>> p: open http://domain.com
>> p/locals/headers/server

SVN revision 93:

o FEAT: new config keyword 'pid-dir for setting user-defined folder 
for Cheyenne's PID file.

o FEAT: Cheyenne's SVN global revision number now appended to Server 
response header.

o FIX: default location for %cheyenne.pid is reverted back to /tmp.

o FIX: PID file now takes the correct process uid:gid when Cheyenne 
is not run as root.

Thanks Doc, this is a really good feature for people who need greater 
security...


Chey.93 now running as user "www" rather than root on our new cloud 
server.

The only alternative would be implementing a continuous-running R3 
application server, instead of using the UniServe taskmaster server. 
But you'd still have the communication overhead between the processes

LNS server doing the cgi

I have a 2.5 K web server here that opens port 80, then switches 
to www uid, and runs fine.

Revision 103 binaries, encapped with enpro 2.7.6:
- Windows: http://cheyenne-server.org/tmp/cheyenne-r103.zip
- Linux libc6 : http://cheyenne-server.org/tmp/cheyenne-r103.gz

Hi Doc, nice list. But would like to ask you, what about a way how 
to terminate long time unused worker processes? They are started 
automaticaly when needed, but there is no way how to stop them when 
the server has no activity.

Encmd binary 2.7.6 for Windows: http://cheyenne-server.org/tmp/cheyenne-cmd-r103.zip
I'll release the other missing binaries tomorrow.

0.9.19.103 binaries for main platforms available now: http://cheyenne-server.org/blog.rsp?view=21

Having changed expire to expires, I get the follioing messages when 
I start up Cheyenne:


29/10-11:48:27.025934-## Error in [uniserve] : Cannot open server 
RConsole on port 9801 !

 29/10-11:48:27.053752-## Error in [uniserve] : Cannot open server 
 Logger on port 9802 !

 29/10-11:48:27.060870-## Error in [uniserve] : Cannot open server 
 MTA on port 9803 !

 29/10-11:48:27.061148-## Error in [uniserve] : Cannot open server 
 HTTPd on port 8000 
!

29/10-11:48:27.061893-## Error in [uniserve] : Cannot open server 
task-master on port 9799 !

For Cheyenne fans, finally some logos to spread everywhere. ;-) 
http://cheyenne-server.org/blog.rsp?view=22

I would prefer to force Cheyenne to execute the script as a real 
CGI Script as I am trying to run REBOL/Services as a CGI script under 
Cheyenne. Ideally, I don't want to have to change the REBOL/Services 
code. (I am migrating a REBOL/Services application away from its 
existing web server and hopefully to Cheyenne. In the longer term, 
it may be possible to convert it to a Cheyenne web app).


Any hints on how to force Cheyenne to run a .cgi file as a real CGI 
script?