AltME groups: search

http://www.websocket.org/is also a good site, it has good info 
about websockets.

by the way, if you use Opera Web Browser and want to test websockets, 
type opera:config to address bar, then type websocket to the search 
box and click on Enable WebSockets.

I most interested in the call back line to send json encoded data...i 
can't get a jquery script to accept anything I send back

And maybe it's a good idea to try to serve some static JSON data 
first instead of generated data to narrow down where the problems 
are.

that seems to be returning javascript (ie. a call to a JS function), 
rather than JSON...

The javascript is looking for the data in a callback...how do I wrap 
the data in a callback using rebol and cheyenne?

Not standalone, you would need a SSL front-end for that, like stunnel 
or nginx.

Cheyenne-server.org is taking a long while to serve the wiki pages.

btw: I added few lines to cheyenne so it solves my only major hurdle 
with javascript (I need to write a lot of javascript for my apps, 
and I use sort of functional style). shorter syntax for anonymouse 
functions + returns. Nothing big or complex...
f{ a, b | .... }  ==>  function ( a, b ) { ..... } 
r{ a, b | a + b } ==> function ( a, b ) { return a + b } 

not sure if it's usefull to anyone else or has place in real cheyenne, 
since it's just more of a hack (and not standard in any way). If 
anyone need it, let me know)

I tried gwan on Windows with a logs directory as described in the 
manual. It crashed.
Also the listen options on startup did not work.

Specifically, it uses a pool of one thread per core for an event 
based architecture

Sqlab, G-WAN for Windows is discontinued, a year ago or so

That was probably when G-WAN had been in development for a year, 
so in any case it would be incomparable to the current Linux version, 
which is not mature yet, either

It should be possible to either extend the AUTH config option to 
specify an "ajax" mode or to add a new AUTH-AJAX config option.

Cheyenne doesn't return HTML when a session times out, it only returns 
a 301 (or 302, I don't remember) to the URL you've specified in the 
config file after AUTH.

yes, that is true.. you make a redirection

as I say, it's not a practical problem for me. :) Just a suggestion.. 
I am making external API and I got some developers that are very 
sensitive to propper HTTP so I am rewriting my api to all those codes.. 
But this is not a problem for that, since API doesn't use cheyenne's 
sessions.. just while I am rewriting my ajax code I thought of it.

In the next days, I will spend a day or two on Cheyenne, to fix a 
few pending issues (like the broken websocket compatibility after 
latest RFC changes).

If you think there's a more general solution to this use-case, let 
me know.

Cheyenne was serving me well for all this time and this is no real 
issue .. just a notice for future maybe

Well, the biggest task is getting websockets up again, modifying 
AUTH should really be a matter of a few lines of code.

I also need to review PHP support as I will make a Cheyenne presentation 
next week at a big PHP meeting here.

So, I will spend at least a day on it.

well .. you decide .. for me it's not a problem, really .. and I 
am also starting to think about HTTP codes now so I don't have the 
clearest view yet

I will have a lot more experiences about this in few months because 
I am just working on this stuff regarding the API and export. I used 
aditional get param so user can select what format she wants. But 
I was educated by this guy that I should look at Accept headers, 
which I ignored happily ..:) .. same about statuses which I didn't 
use. Now I am getting home at this, so we can talk in a while and 
determine the most systematic and clean way for this. And such that 
will make the REST purists happy

I think that Gabriele could also have some good inputs on the best 
practices to support, as he's doing a lot of AJAX programming.

My main server is down since a few hours due to a non-technical issue. 
This affects all the following web sites:
- cheyenne-server.org
- curecode.org
- part of red-lang.org


The problem should be solved in an hour. This server is still owned 
by my former company, Softinnov, who forgot to do the renewal in 
time.

Too bad I thought it was a hardware issue and I sent a reboot from 
the control panel, just a few seconds before realizing that the server 
plan has expired. The server was running since 670 days uninterrupted.

I think its ok to use append if its not a heavy-loaded web site. 

I did this to prevent possible file access problem if it happens 
same time in very rare cases:

		unless 'ok = loop 3 [
			if not error? try [
				save voter-file append voters session/content/username
			] [
				break/return 'ok
			]
			wait 0:0:0.1
		] [
			response/redirect "error.rsp?code=error-on-voting"
		]

You can use debug/* logging functions, but they will only log in 
%trace.log file. Writing directly to a log file from RSP script is 
unsafe (unless you take great care about concurrent accesses). So, 
if you want to have custom logs from RSP scripts, you should use 
the OS syslog service for a really realiable solution. The debug/* 
log functions use their own solution for serializing disk writes, 
they are passing data to Cheyenne main process that does the writings 
to disk.

You could also make your own syslog server with 0MQ and send log 
messages to it from RSP scripts. That will offload the writing to 
a different process and 0MQ will take care of serialisation

Endo, thanks for the code. I will need something similar for sqlite. 
I just got a first db is locked error yesterday with it at UsrJoy.


What I'm trying to log is side-info (like usage info) so I don't 
want to inpact the speed of response by having aditional disk write 
in the request-response process (it has to be async).


Doc: I used debug functions for various info logging too now (and 
I do diff on trace in cron and send myself email if there is any 
difference), but I am trying to log more things and I would like 
to leave trace.log for errors only. I was interested if the existing 
functionality that serializes debug to trace.log could be used to 
log to some other file. like info.log . That would complicate the 
app-code the least.. otherwise I was thinking of what  Kaj  proposed, 
to have some queue to send data over via tcp to and it will write 
it to disk in intervals. That would bring another dependancy into 
app-code.. something like redis could automatically work like this 
I think.

The probably best option would be for Cheyenne to spawn a new process 
that would handle all the log files serialization (both for Cheyenne 
internal use and for web apps). The code for that is already bundled 
in Cheyenne main process, so it would not be a big work to extract 
it and spawn a new process. (but would require at least a couple 
of days, including testing).

It makes heavy requirements on the file locking of the operating 
system for that, and it does have a document section that explains 
how operating systems are buggy and badly documented, so that doesn't 
exactly instill confidence

Reliable and efficient file locking is hard to achieve, I agree with 
that. That's why I went for a syslog-like solution for Cheyenne.

http://www.sqlite.org/faq.html#q5


Multiple processes can have the same database open at the same time. 
Multiple processes can be doing a SELECT at the same time. But only 
one process can be making changes to the database at any moment in 
time, however.

When any process wants to write, it must lock the entire database 
file for the duration of its update


However, client/server database engines (such as PostgreSQL, MySQL, 
or Oracle) usually support a higher level of concurrency and allow 
multiple processes to be writing to the same database at the same 
time. This is possible in a client/server database because there 
is always a single well-controlled server process available to coordinate 
access. If your application has a need for a lot of concurrency, 
then you should consider using a client/server database.

Those locks last only a fraction of time imo. Shouldn't it be good 
for small stuff?

Bad news for websocket support in REBOL: the new RFC requires that 
client encodes data sent to server using a basic XOR encryption algorithm:


http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-4.3


This is a bad news for us, because it requires to process all bytes 
received, one by one to decode the message. REBOL is very slow at 
processing big data in loops, so the overhead can be very significant 
for data frames of a few dozen KB and more. It could affect Cheyenne 
global performances drastically.


However, it could have been worse, this encryption scheme is not 
required for data sent by server. So, as long as clients are sending 
small messages (up to a few KB), the overhead should be low. Fortunately, 
the usual client messages are queries to obtain data, so usually 
small. But if you have to move big amouts of data (like XML documents) 
back and forth through websockets, Cheyenne won't be able to cop 
with the load and it will most probably be a show-stopper.

Can it be solved by calling a routine from a dynamic linked library?

Yes, but in Cheyenne context, having to maintain a cross-platform 
C lib to that would be really annoying. It would be the end of Cheyenne 
as a one-file server. Also, it wouldn't run on Core anymore.

I have pushed a preliminary implementation of the latest websocket 
RFC to Cheyenne SVN repo. It works only for text messages of size 
< 126 bytes. I will get back to it in the next day and complete it.

I guess yo would need to modify the RSP engine for that. The easiest 
way would probably be to create a custom 'include function able to 
decrypt your files.

I think that the cleanest way would be then to extend the existing 
INCLUDE function in RSP.r by adding a refinement (/with or /options) 
and use it to pass additional custom data to the INCLUDE function 
(like a 'decrypt word, followed by a key).

You could add a property to ENGINE object for controlling how files 
are loaded, and set/unset it depending on INCLUDE refinement.

about encap: I'll try to find the problem and if it's not difficult 
I try to fix it as well. I wanted to ask before spending time on 
it. Thank you. Doc: if you already done / test it please let me know. 
I'm planning to use it in a production.

I'll do a quick test on that just after finishing the websocket implementation.

Should be in a an hour or two.

Btw, a RSS feed is available for the Cheyenne blog.

There was about 25 people in the audience, a lot moved to other, 
more PHP-focused, conferences at the same time.

Some were very interested by a simple, small and easily deployed 
web server that could run PHP code efficiently.

Janko: I have extended AUTH to be able to return an HTTP code in 
revision 157:


FEAT: AUTH config keyword can now take an optional second parameter 
(HTTP code 4xx or 5xx) that will be returned to client instead of 
a redirection to the login URL.

The first parameter (a URL) is mandatory and should point to the 
resource where login happens (it's a pass-thru, every other URL will 
be redirected or will return a custom HTTP code, if specified).

Endo: I have pushed a few fixes for regressions in embedded mode 
support. I'm now looking into the possibility of encapping it that 
mode.

I have added a few lines to embed-demo.r to show you how to prepare 
it for encapping with Cheyenne running in embedded mode: 
http://code.google.com/p/cheyenne-server/source/detail?r=161

Fantastic! Thanks a lot Doc! Now I can make show to my manager for 
our next project :)

I did not yet test but with this way we can easily write a websocket 
test server application.

Btw, the embedded mode is for providing an HTTP server to an existing 
app, not a full-featured Cheyenne. If you want to make a GUI app 
in View for just a few simple interaction with Cheyenne, you can 
just #include your View code in %cheyenne.r.

I pushed a fix in the repo.

Works great. Thank you!

the embedded mode is for providing an HTTP server to an existing 
app, not a full-featured Cheyenne
 But I can use RSP, websockets and webapps I think, right?

If you want a full-featured Cheyenne and integrate your own GUI app, 
you would have to make it the other way around, which is include 
your app in %cheyenne.r.

Oh but there a "testapp" in embed-demo.r? and its not plain HTML.

As the (long) note explains it, it's a special API for closely integrating 
Cheyenne HTTP server with an existing app.

Ok, now I got it. Thanks a lot.

oh sorry :) use CALL in a function :)

Yes, you can also use CALL in a function if you prefer.

Wow something weird happened.. 

jobs [every 5 s do %test.r] --> creates a new cheyenne process every 
5 seconds

%test.r --> REBOL [] print now

CALL is a better option I guess.

I think you can (if you know how to build a "handler" for Task-master).

You might have to use a longer access path like: uniserve/shared/do-task

Thank you. I'll try.

What I'm working on is, to poll a database table and send some changes 
to a client on a web socket. polling should not block Cheyenne of 
course.

Right, it's a side-effect of on-timer, I should fix it somehow to 
avoid that message.

You can just pass a block! value as a job to the scheduler and call 
your code from there, it would be cleaner than hacking in on-timer.

One last thing: in ws.html there is a button to close the connection:

<button onClick=" alert('button closed');conn.close();"> Disconnect 
</button>


But I never get onClose event and don't see a connection close on 
server logs:
conn.onclose = function(evt) { alert("Conn closed"); }

And "tick"s appear even if I click on Disconnect.

When I remove AUTH line from WEBAPP section in httpd.cfg file, the 
browser always returns :ERR_EMPTY_RESPONSE error.
Here is my part of httpd.cfg
	webapp [
		virtual-root "/testapp"
		root-dir %www/testapp/
;		auth "/testapp/login.rsp"
		;debug
	]


in %testapp/  I have test.html and test.rsp they both very simple 
files, I have app-init.r also. But I can never access those files.
In Cheyenne log file I see following error:


10/12-3:11:39.3120-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'second
    arg2: 'series

    arg3: [series! pair! event! money! date! object! port! time! tuple! 
    any-function! struct! event!]
    near: [either url: second pos: find]
    where: 'process-webapp
] !


As a work around I put auth line to a rsp file that just do session/content/login?: 
yes and redirect. 
Do you have any idea? I tested with 0920 and r164.

Doc: "You can just pass a block! value as a job to the scheduler 
and call your code from there, it would be cleaner than hacking in 
on-timer."

How do I interact with "clients" connected via ws inside a "job" 
block?

I have "clients" block in on-timer event and I able to send messages 
to them. Is it possible from jobs?

2) in ws-test-app.r file it says do-task/on-done takes an argument 
that can be anything.

But when call do-task/on-done with any non-string argument I get 
an error, am I doing something wrong?

I tried with a port (connected ws client) and a integer, both failed:


11/12-6:17:04.1090-## Error in [mod-socket] : On-timer call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'do-task
    arg2: 'data
    arg3: [string!]
    near: [do-task/on-done 5 func [client data] [
            send client join "Job end: " reform [now/time tab i]
        ]]
    where: :action
] !

AUTH regression (error when not used in a webapp): fixed in last 
revision.

It's a not big issue, but I noticed, that the include function does 
not removes BOM from the files. Do you think it's worth to improving 
it or let people to maintain it manually in the files which are being 
included?

Browsers like Chrome or Firefox are fine if find a BOM inside html, 
but for example IE6 had a problem - at least in my case. So far I 
just resaved my source, but I can imagine that it will reappear in 
a future again (as UTF8 with BOM is default).

Sounds like a good idea (making INCLUDE remove UTF-8 BOM, if found).

I'm trying to generate an .rsp page based on a query string the way 
a cgi page does using 'decode-cgi system/options/cgi/query-string'

but it does not seem to be working. How is this sort of thing done 
with .rsp?

Here's a function I use to remove BOMs I got from Windows files:

read-lines: func ["Read text lines from a file."
	file [file! url!]
	/local line
][
	if all [not empty? file: read/lines file
		find/match line: first file  "^(EF)^(BB)^(BF)"
	][
		remove/part line 3  ; Remove BOM
	]
	file
]

Two things:

1. what is the mechanism that determines the name of a log file?
2. would it be a bug, if I saw a log file named none-access.log?

1. Depends on which log file you're thinking of, I guess it's for 
HTTP access logs. It's composed by virtual host name followed by 
"-access.log".


2. It could be an internal bug or a misconfiguration issue, anyway, 
Cheyenne should not produce such files.

OK. I saw it as a REBOL process was suddenly racing at 100% CPU. 
Someone accessed my site, which posted an entry in the default-access.log 
with an HTTP 1.0 request:


74.52.168.98 - - [25/Dec/2011:10:30:29 +0100] "GET / HTTP/1.0" 200 
9


Then 5 minutes later, the none-access.log appears and I'm flooded 
with requests until that log is 45 MB in size.

The file starts like this:

.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
.... 45 MB of this

Hmm, intriguing...Seems that you received a request with garbage, 
either an attack or flooding attempt. The HTTP/1.0 suggests that 
the request is not coming from a web browser (all are using HTTP/1.1 
now).

That could explain the "none-access.log" file, if the request doesn't 
have a Host field defined.

It also could be a regression in Cheyenne for HTTP/1.0 support, I 
would need to check that. The huge number of log entries suggests 
that Cheyenne is trying to interpret incoming data as pipelined requests, 
instead of just dropping it down.

(that is not a paste error)

Truncation: that could be caused by a bug in the HTTP access log 
batch writing, the log cache seems to have been desynchronized by 
the request.

I have a working session on Cheyenne planned tomorrow, I will have 
a look at the issue more closely.

I've tried a lot of different hand-crafted request to try to crash 
Cheyenne and reproduce your issue, but Cheyenne is keeping responding 
right.

Are you using a PHP engine through FastCGI?

no, pure REBOL. I found now that using READ inside app-init.r causes 
this hang for a worker process as well.

I'm getting a number of very strange things. DO doesn't work either.

aha, so errors are buried a bit deeper than I thought.

If you upgraded from a really older version, you might get some issues 
with the libraries loading from app-init.r as DO behaviour was changed 
in more recent versions.

Maybe this is interesting: Causing a DoS by reading server responses 
very slowly:


https://community.qualys.com/blogs/securitylabs/2012/01/05/slow-read

The plink example didn't work for me. I got the following message:


>> win-call/output "plink.exe -l user -pw password [checkall-:-host] 
 df "  str: make stri
ng! 102

4
== {CreateProcess failed!: The system cannot find the file specified.}

Though I got a similar message from the console:

C:\Documents and Settings\Peter>plink.exe -l user -pw password [checkall-:-host] 
 df

'plink.exe' is not recognized as an internal or external command,
operable 
program or batch file.