AltME groups homeHelpJoin REBOL3 world

Recent posts

Worlds:r4wpr3wp
AccessibilityAbout / FAQ
Member's loungeContact/FeedbackOther REBOL links
Membership:
member name

password

Remember?

Not a member? Please join
1-May 0:00 UTC
[0.25] 52.127k
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

AltME groups: search

Find AltME posts
Help · search scripts · search articles · search mailing list

results summary

worldhits
r4wp141
r3wp1905
total:2046

results window for this page: [start: 1601 end: 1700]

world-name: r3wp

Group: !Cheyenne ... Discussions about the Cheyenne Web Server [web-public]
Dockimbel:
15-Oct-2009
I've added your virtual domains definition to my httpd.cfg file, 
added a root-dir to domain.com, added :81 to the redirection URL, 
mapped both domain to localhost, changed domain.net's root-dir to 
%www/testapp and it works ok :

>> read http://www.domain.com:81
connecting to: www.domain.com
connecting to: www.domain.net
== {<html>
<head>
^-<title>Welcome to TestApp web application</title>...
Maxim:
15-Oct-2009
it has the advantage of freeing the load from the web server so it 
can continue to stream data... and some client work using several 
inter-connected cheyenne servers actually provides good results, 
so I'm optimistic so far  ;-)
Maxim:
15-Oct-2009
is there any documentation on the concepts of web-apps?  is this 
an rsp-specific cheyenne concept?
Maxim:
15-Oct-2009
ok I looked at web apps... remark is basically an uber web-app architecture... 
all it needs are a few more configs.
I'll add this in the second release of the mod
Dockimbel:
15-Oct-2009
Only from close friends living in the java world, beyond them, no 
one. I don't expect much from outside REBOL world yet, Cheyenne is 
mainly useful for REBOL programmers. Once it reaches 1.x, Cheyenne 
will have features that would make it more interesting for outsiders 
(like a simple web control panel, web sites and webapp packaging 
in one unique executable, on-demand ready-to-use web application 
loading from our servers: blog, forum, bugtracker,...). I may also 
add a FTP service in a future 1.x version and a lot of other innovating 
new features I have in mind. ;-)
Terry:
8-Nov-2009
Hey Doc, how would you deal with an async socket (or .dll) that received 
events allowing realtime updates on a Cheyenne web page?
Kaj:
9-Nov-2009
There's nothing specific you have to do on the web server side except 
providing the service interfaces (regular HTTP responses)
Terry:
10-Nov-2009
I want to unify communications using Cheyenne (Rebol) as the middleware, 
pulling and pushing info through and to each other

ie: an event message from Freeswitch is processed via xml socket, 
processed, and pushed to a web page via comet / ajax.. and back again..
Kaj:
10-Nov-2009
I'm not sure it makes sense to let Freeswitch initiate events, because 
you can' t push them to the web browser, anyway. The browser will 
have to poll
Endo:
15-Dec-2009
I can download it from the web
Graham:
21-Dec-2009
and other web apps
Dockimbel:
21-Dec-2009
Hmm, I think that the way I've used "webapps" in my previous msg 
is confusing, I was referring to a "web application" built using 
RSP scripts not the "webapp" keyword used in config file. A web application 
(along with its app-init.r file) is unique. OTOH, a webapp config 
is per virtual host.
Terry:
22-Dec-2009
web sockets are an HTML 5 spec
Terry:
22-Dec-2009
I imagine you could build a web socket protocol with Cheyenne in 
a few hours.. would take me a week
Dockimbel:
22-Dec-2009
Apache already supports web sockets using a python plugin : http://code.google.com/p/pywebsocket
Terry:
22-Dec-2009
Here's the W3C Web Sockets API if you're feeling so inclined. 
http://dev.w3.org/html5/websockets/#the-websocket-interface
Terry:
22-Dec-2009
Not sure if you recall, but the work I was doing with Cheyenne was 
trying to implement  Web sockets before Web sockets even existed.
Terry:
22-Dec-2009
It's pretty straight-forward.. check out this PHP web socket server 
.. 140 lines

http://code.google.com/p/phpwebsocket/source/browse/trunk/phpwebsocket/server.php
Kaj:
22-Dec-2009
Will, such Comet solutions will probably include web sockets soon, 
as web sockets is an advanced form of Comet
Will:
22-Dec-2009
As of now there are no browsers that supports websockets, apart from 
Chromium http://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html

meanwhile kaazing emulate that for older browsers http://www.kaazing.org/confluence/display/Doc/Architecture+Overview#kegfeatures
Kaj:
22-Dec-2009
I have to research more, but it seems the http://js.iolibrary adds 
web sockets to older browsers
Kaj:
22-Dec-2009
The trick is that web sockets needs a little server support to down/upgrade 
(as you see it) a HTTP connection to a more flexible TCP connection
Kaj:
22-Dec-2009
But once it's a web standard, they can't have the nerve to close 
it off anymore
Terry:
22-Dec-2009
Web sockets are not an advanced form of Comet.
Terry:
22-Dec-2009
Though Comet and Ajax can both deliver end-user experiences that 
provide desktop-like functionality and low user-perceived latency, 
only Web Sockets lives up to the promise of providing a native means 
to accurately and efficiently stream events to and from the browser 
with negligible latency. It is by far the most comprehensive solution 
for delivering real-time information over the Web. Not only does 
it provide full asynchronous duplex streaming communication with 
a single TCP/IP connection, but also benefits from few HTTP headers 
and more importantly allows the same message format to be used by 
both the browser and the origin service.
Kaj:
22-Dec-2009
Well, it's a matter of definition. They're very similar, but web 
sockets require the server support
Kaj:
22-Dec-2009
It seems js.io is an alternative to web sockets. If it's true that 
web sockets need native browser support just like the server side, 
Comet will still have a long life
Kaj:
22-Dec-2009
Still, I'm now considering the same as you. If I bundle Chrome with 
Syllable, by the time I am progressing with a few web apps, web sockets 
may have penetrated far enough to not bother with Comet
Graham:
22-Dec-2009
I've got this really odd situation ... I have Cheyenne and the rebol 
micro web server both running.  Cheyenne is on 8002, and MWS on 8001.
Both share the www directory.

at times I access a file and I get a 404 from Cheyenne but the MWS 
can find the file!
Dockimbel:
22-Dec-2009
Found a cool example for future Cheyenne web sockets : http://www.onlinegames.com/basketball/
Dockimbel:
24-Dec-2009
FYI: I've implemented the web socket protocol in Cheyenne last night 
(not released yet) but I still need to figure out how to properly 
interface incoming data frames with the RSP engine.
Graham:
24-Dec-2009
Is there a dummies for web sockets to explain what this does?
Graham:
24-Dec-2009
And are people then running BEEP over web sockets?
Kaj:
24-Dec-2009
Since it's being standardised as web technology, there will be a 
big social barrier for firewalls to start blocking it
Dockimbel:
25-Dec-2009
SVN r45 : Web Sockets support


FEAT: experimental Web Sockets support added. (See %www/ws.html and 
%www/ws.rsp)
FIX: regression on bad HTTP request filtering. (Thanks to sqlab)
FIX: minor code clean-ups.
Dockimbel:
25-Dec-2009
You'll need Chrome 4 to be able to use web sockets (don't know about 
other browsers).
Dockimbel:
25-Dec-2009
Currently, your web socket URL must point to an existing RSP script 
(or a path that translates to a RSP file). The included %ws.rsp script 
is just a simple echo service.
Dockimbel:
25-Dec-2009
Once connected, all the web socket traffic is directed to the starting 
RSP script, where you can implement your own application specific 
protocol and action dispatching while benefiting from the RSP webapps 
features (like the webapp filesystem structure with private/public 
folders).
Dockimbel:
25-Dec-2009
Server-side 'connect and 'close sockets events are missing. Not sure 
how easy it will be to add them to the RSP application model. More 
generaly, the web sockets require a shift in the whole application 
model, the RSP engine is tuned to request/response model, not client/server. 
I'm not even sure that such server can be built in a efficient way 
with REBOL without multi-threading support (can't share port! values 
between processes).
Dockimbel:
25-Dec-2009
Just think about how a minimalistic multi-user chat app could be 
built using web sockets. The application code needs to be able to 
access all the existing connected sockets to broadcast user posts, 
but these sockets are connected to the main process (UniServe) while 
the application code is run in worker processes...Having everything 
in one process would solve that but you can't run any scalable app 
with such model (beyong just passing messages between sockets). That's 
where mutlti-threading would have been useful...
Graham:
25-Dec-2009
Does this mean you can now  more easily write a web control panel?

And does it make it easier to use Cheyenne's mail server?
Dockimbel:
25-Dec-2009
Graham: you should check if your server is reachable on this URL 
: http://localhost/ws.rsp(it should if you're using the config file 
from SVN). 


Web Control Panel : yes, it's easier with web sockets than with COMET 
approach, but it's not a show stopper anyway.

Mail server : it could make it easier if you're using a client supporting 
web sockets.
Dockimbel:
25-Dec-2009
My thought would be a business layer managing sockets?

 If you want a kind of bridging server (web sockets<=> Server <=> 
 TCP), there's already existing products doing that like http://www.kaazing.com/products/kaazing-websocket-gateway
Terry:
25-Dec-2009
Well, there's already existing web servers as well. .That's not the 
point.
Dockimbel:
25-Dec-2009
Important notice wrt web sockets : IIRC, all data sent on both sides 
have to be UTF-8 encoded. The current Cheyenne implementation doesn't 
enforce that encoding, so it's up to the developer to send the right 
data format.
Terry:
25-Dec-2009
Here's quick demo of pushing javascript back for eval

---------WS.html--------------


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<title>Welcome!</title>
	

<script src='http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js'</script>

<script src='http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js'</script>	

</head>
<body>
<center>
<h2>Web Socket test page</h2>

<script>
var conn = new WebSocket("ws://localhost/ws.rsp")

conn.onopen = function(evt) {
 alert("Conn opened");
}
conn.onmessage = function(evt) {
 eval(evt.data); 
 }
conn.onclose = function(evt) {
 alert("Conn closed"); 
}


</script>

<button onClick="conn.send('Hello World');"> Send Message </button>
<button onclick="conn.send('makedrag');"> Make it drag</button>
</center>


<div id="test" style="height:100px;width:100px;border: 1px solid 
grey">MAKE ME DRAGGABLE</div>
</body>
</html>

-------WS.rsp------


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<title>Welcome!</title>
	

<script src='http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js'</script>

<script src='http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js'</script>	

</head>
<body>
<center>
<h2>Web Socket test page</h2>

<script>
var conn = new WebSocket("ws://localhost/ws.rsp")

conn.onopen = function(evt) {
 alert("Conn opened");
}
conn.onmessage = function(evt) {
 eval(evt.data); 
 }
conn.onclose = function(evt) {
 alert("Conn closed"); 
}


</script>

<button onClick="conn.send('Hello World');"> Send Message </button>
<button onclick="conn.send('makedrag');"> Make it drag</button>
</center>


<div id="test" style="height:100px;width:100px;border: 1px solid 
grey">MAKE ME DRAGGABLE</div>
</body>
</html>
Terry:
25-Dec-2009
WS.rsp  should look like this

<%

;-- RSP API web sockets specific changes --
;

;   request/web-socket? => true if this is an incoming socket message, 
false if it's HTTP.
;   request/content/data => contains the socket message (string!)

;-- just echo back the message
//prin request/content/data

inc: request/content/data
if inc = "makedrag" [prin "$('#test').draggable();"]  

if inc = "Hello World" [prin "alert('Hello back');"]
 
%>
Dockimbel:
25-Dec-2009
Btw, the Internet Draft defining the web socket protocol (http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54) 
is really badly written. In particular, algorithm descriptions are 
incredibly obfuscated. On the design side, a packet-oriented protocol 
not sending packet length (for text frames), rather relying on begin/end 
markers, is a surprizing choice to me.
Graham:
25-Dec-2009
And if i browse to http://localhost:8000/ws.html .. I see the web 
socket test page, and I get a Chrome alert saying that Conn closed.
Dockimbel:
25-Dec-2009
Terry: after taking the time to think about your comments regarding 
how web sockets should be integrated in UniServe & task-master, it 
starts to make sense and it inspires me on how it could be done and 
how the framework could look like. I'm writing a few specs on paper 
and will maybe implement a prototype tomorrow. This web sockets stuff 
is really going to be exiting after all. ;-)
Dockimbel:
25-Dec-2009
My goal is to be able to write the server side of a web app like 
this one (2k concurrent users on average)  http://www.onlinegames.com/basketball/
using Cheyenne & a web sockets framework with minimal efforts and 
good scalability.
Dockimbel:
26-Dec-2009
Looks like I'm not the only one ranting about web sockets protocol 
specifications : http://blogs.webtide.com/gregw/entry/how_to_improve_websocket
Graham:
27-Dec-2009
Anyone got an example of how to connect to the web socket from a 
rebol client?
Dockimbel:
27-Dec-2009
ws.rsp script is supposed to be accessed only through web sockets 
: ws://localhost/ws.rsp
Dockimbel:
27-Dec-2009
This URL is not be typed in your browser address, it's for the web 
socket object creation in javascript. Please, have a look in %www/ws.html.
Dockimbel:
28-Dec-2009
the connection is open, but RSP is stateless

 If you want to make it stateful, just store the data in session, 
 file, database, whatever...Most of RSP API is still working with 
 web sockets (response object methods will have no effect).
Dockimbel:
29-Dec-2009
Terry, wait to try the new web socket framework I'm working on. It 
should be ready tonight (if I find time to finish testing and debugging).
Dockimbel:
29-Dec-2009
SVN r46 : web socket application framework released.
Dockimbel:
29-Dec-2009
I'll finish the pending items tomorrow and will try to provide a 
more fancy example by building a realtime web chat application.
Terry:
30-Dec-2009
Script: "Cheyenne Web Server" (8-Mar-2009)
Script: "Untitled" (none)
make object! [
    code: 300
    type: 'script
    id: 'no-value
    arg1: 'scope
    arg2: none
    arg3: none
    near: [either root: select scope 'root-dir]
    where: 'read
]
Dockimbel:
30-Dec-2009
do-task allows you to have multitasking in you web socket application. 
Internally, it  re-uses the task-master service and the RSP IPC system. 
That way, you can easily integrate one or several web socket service 
or applications in existing RSP scripts or webapps.
Dockimbel:
30-Dec-2009
do-task in this example, sends the raw incoming data from the browser 
to a worker process using ws.rsp script to generate a response that 
is sent back to the web socket app (if a /on-done callback has been 
defined) or directly to the client browser.
Dockimbel:
30-Dec-2009
Yeah, you could make a realtime RSS feeder easily with web sockets.
Terry:
31-Dec-2009
I think I'm lost (happens all the time).  Let's say I want to poll 
a remote web page for screen scraping (or remote php processing) 
every 2 seconds, and pass that to a specific port.. I would do this 
from the 'socket-app, no?
Terry:
31-Dec-2009
Now lets say the client hits an event on the web page, and now i 
want the timer to visit a different remote web page.. how would i 
pass that event to the timer?
Dockimbel:
31-Dec-2009
SVN r51
FEAT: /ws-apps folders are now protected from direct access.

FEAT: modified socket apps source files are reloaded and used by 
new clients.

FIX:  web socket application's 'session object renamed to the more 
accurate 'rsp-session.
FIX:  'do-task calls now supported in 'on-timer handler.
FIX:  scheduler issue with deleted jobs.
Dockimbel:
31-Dec-2009
That comes from the way web socket's connection are initiated, it 
starts like a simple HTTP GET request and the server is supposed 
to validate that request, check access authorization if required, 
etc... So, to avoid duplicating work, I choose to re-use RSP framework 
as much as possible. The initial ws:// URL must point to a valid 
RSP script so that the server can check, for example, RSP session 
cookie for access rights.
Graham:
3-Jan-2010
doc is going to create some type of demo using web sockets
Will:
3-Jan-2010
here is a flash based websocket so you can support old browsers and 
use websockets now 8-)  http://github.com/gimite/web-socket-js
Dockimbel:
3-Jan-2010
My demo is ready, but I found an issue to fix first with HTTP keepalive 
connections timeout colliding with web sockets timeout. The demo 
should be ready to try in a couple of hours (lunch time here).
Dockimbel:
3-Jan-2010
Web sockets server-side support code is much shorter than HTTP, so, 
in theory, it should scale higher.
Dockimbel:
3-Jan-2010
Ah, maybe not with web sockets long-lasting connections...
Will:
3-Jan-2010
here is WebKit Web Socket design doc for anyone interested http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Dockimbel:
3-Jan-2010
SVN r52
FEAT: web socket realtime chat demo added.

FEAT: changed socket application's SEND function specs to SEND client 
[port!] data [string!] (/with removed).

FIX:  timeout web socket issue clashing with HTTP keepalive timeouts. 
Web socket ports are no more timed out after 15sec.
Dockimbel:
3-Jan-2010
Seems that the chat demo becomes the standard way to demo web sockets. 
:-)
Dockimbel:
3-Jan-2010
No, the bindind between the URL (/chat.rsp) and the web socket app 
(chat) is done in the httpd.cfg file with the 'socket-app keyword.
Dockimbel:
3-Jan-2010
Got the chat demo running online. If you have a web socket enabled 
browser (ex: Chrome 4), go visit here : http://demo.cheyenne-server.org:8080/chat.html
Dockimbel:
3-Jan-2010
Hope this will inspire some of you to ride the new wave of realtime 
web application that will surely start to come this year.
Davide:
3-Jan-2010
this web chat is using websocket on chrome (and comet in other browser).
http://www.ddmind.com/modules.php?name=gdp_easy_chat

It's a Rebol server and It works pretty well...great uptime and low 
cpu use.
Kaj:
3-Jan-2010
http://www.osnews.com/story/22681/Syllable_Web_Server_Cheyenne_Gets_WebSocket_Framework
Dockimbel:
3-Jan-2010
For web socket apps, the advantage would be to not have to require 
'do-task to use the sync version of these protocols from a worker 
process. OTOH, that would put more burden on the main process lowering 
its scalability. So I've not decided yet, this would probably require 
good benchmarking first.
Kaj:
3-Jan-2010
I had hoped it would be in time for OSNews, but I thought I had better 
make use of the current slow news period. I'm not sure they would 
report on just some web server
BrianH:
5-Jan-2010
All good criticisms, except the "proprietary" one. It could be worse 
though - it could be a web chat.
Terry:
5-Jan-2010
Yeah, web chats....  avatars, skins, website integration, API integration 
with gmail, animations, sound, video and other media integration... 
those things really suck
BrianH:
5-Jan-2010
Yup, I agree, at least the parts that need the web to do (which isn't 
much on that list).
Kaj:
5-Jan-2010
Web chat it will be
BrianH:
5-Jan-2010
It's funny, Terry, but I keep agreeing with your sarcastic list once 
I filter out the stuff that I can do easier without a web browser, 
or that aren't necessary at all when you aren't using one.
BrianH:
5-Jan-2010
Server-side web stuff is fun though.
Dockimbel:
6-Jan-2010
Thanks Terry, I've upgraded the chat demo with most of your changes. 
I've also included an alert message for non-compliant web browsers.
Dockimbel:
7-Jan-2010
Cookies: well, it would be a nice addition to a real chat app, but 
the point in this demo is to show web socket usage, not to build 
a full-featured chat app. If you want to build a full chat app, you're 
free to take my demo code and extend it as far as you wish.
Dockimbel:
7-Jan-2010
PHP connection: it should be possible with minimal modifications, 
but why would you want that? Is there any  significant PHP socket 
app yet ready to use? My goal in adding web sockets early in Cheyenne 
is to push developers to make nice apps in REBOL, not PHP.
Dockimbel:
7-Jan-2010
That may be possible, but would be more complicated to support than 
web sockets as the server can't send data without getting a request. 
It will be hard to extend the web socket application framework without 
bloating it. Maybe a separated mod-comet would be a cleaner approach 
(but might duplicate a Iot of code in mod-socket). I will give it 
a look anyway, at least to estimate the time required to support 
it.
Dockimbel:
7-Jan-2010
Terry, the point is that if you want to make PHP apps, you should 
better stick with another web server more adequate to PHP like Apache 
or Lightttpd. Cheyenne's PHP support has been done mainly to be able 
to integrate existing PHP apps in REBOL powered web sites, not build 
new ones.
Dockimbel:
7-Jan-2010
It's not a matter for me to favor REBOL against PHP for builting 
apps (everyone is free to choose), but just that there are better 
tools to run PHP code than Cheyenne. OTOH, I'm not sure there's better 
choice currently than Cheyenne to run REBOL web apps.
Dockimbel:
7-Jan-2010
Btw, the target market that was at the origin of Cheyenne project 
was home web servers, both for local and external use (serving files 
and apps from your home connection). The main feature was supposed 
to be simplicity of use through a very simple, but powerful control 
panel, and on-demand app loading (something like App Store, but for 
web apps). Another market that we've thought about was portable embedded 
web apps (server + apps bundled in a single exe with 0 install, 0 
config).
Dockimbel:
7-Jan-2010
Still needs an improved virtual filesystem to easily run RSP web 
apps from memory, but for custom embedded REBOL apps, it should work 
ok.
Pekr:
7-Jan-2010
what Terry tries to say imo is, that nowadays the web proceeded, 
and it is much more dynamic, so that even RSP sounds old-school ...
Terry:
7-Jan-2010
Speaking of threads.. Along with Websockets, HTML 5 comes with Webworkers 
(supported by Chrome as well)


Workers provide a simple means for web content to run scripts in 
background threads.  Once created, a worker can send messages to 
the spawning task by posting messages to an event handler specified 
by the creator.
The worker thread can perform tasks without interfering 
with the user interface.  In addition, they can perform I/O using 
XMLHttpRequest (although the responseXML and channel attributes are 
always null).
The Worker interface spawns real OS-level threads, 
and concurrency can cause interesting effects in your code if you 
aren't careful.

https://developer.mozilla.org/En/Using_web_workers
Terry:
7-Jan-2010
Nope, wrong again.. workers are fine in Chrome.. that last demo only 
works with FF

Here's some other demos on Resig's page  
http://ejohn.org/blog/web-workers/
Terry:
8-Jan-2010
Here's some code that uses flash as a websocket proxy for browsers 
that don't support websockets
http://github.com/gimite/web-socket-js

Needs some tweaking, particularly with ports.
1601 / 204612345...1516[17] 18192021