World: r3wp

Some advantages to the ws:// spec

- Seamlessly traverse firewalls and routers
- Allow duly authorized cross-domain communication
- Integrate well with cookie-based authentication
- Integrate with existing HTTP load balancers
- Be compatible with binary data

Another good read on the subject
http://cometdaily.com/2008/07/04/html5-websocket/

I think that it's simple enough to be implemented in a couple of 
hours including reading the full specifications.

I might give it a try tomorrow. ;-)

That would be awesome

I would definitely upgrade then ;-)

Ah, now I got a real motivation to add it. ;-)

:-)

So Terry is this obsolete stuff? http://www.ape-project.org/

Seriously, I'm simply using the Cheyenne I integrated into Syllable 
Server 0.3. Hope to postpone upgrading Cheyenne and other packages 
until I release a complete new Syllable Server

Will, such Comet solutions will probably include web sockets soon, 
as web sockets is an advanced form of Comet

But then, all the complexity of the Comet solutions will definitely 
look out of place

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

I have to research more, but it seems the http://js.iolibrary adds 
web sockets to older browsers

post got grumbled, kaazing also cope with older browsers

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

Of course, we had that since the birth of the Internet. This is effectively 
just an idiotic workaround to get our Internet back from firewalls

But once it's a web standard, they can't have the nerve to close 
it off anymore

Will: I would say Comet is obsolete.. Comet is a hack at best.

Web sockets are not an advanced form of Comet.

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.

Well, it's a matter of definition. They're very similar, but web 
sockets require the server support

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

Janko: "About code loading on on-page-start : yes I know of that, 
I am using it as dev setup so I know latest code is reloaded each 
pageload." 


There's an easier solution for that: add -w 0 argument to Cheyenne's 
command line, this will ensure that the worker process will be reloaded 
for each new request. Here's the command line I use to run Cheyenne 
on my development boxes : C:\Dev\SDK\tools\rebcmdview.exe -s cheyenne.r 
-vv -w 0

Kaj, "long life" is a relative term.  I suppose it depends on the 
service. If i build a service that lets you access my killer app, 
but say "you need to use Chrome" then 'long life'  may be irrelevant.

To you, but Comet will live happily ever after. :-) Anyway, I know 
what you mean

The point is that there can be no killer app targeting just a few 
percent of the market

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

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!

It's as though Cheyenne is looking elsewhere ...

my httpd.cfg root-dir is pointing correctly to the right directory, 
and I have an exception for cheyenne.exe in the windows firewall.

I never saw this issue under Window XP, or Vista and I'm running 
on Windows 7 Professional.

Looks like my application is writing files to a hidden directory 
somewhere which the MWS can see, but Cheyenne can't see.

Must be some type of windows redirection

or UAC virtualization

So, not a Cheyenne issue ...

Cheyenne is looking in the right place,  but my app writes are being 
redirected somewhere else.

Found a cool example for future Cheyenne web sockets : http://www.onlinegames.com/basketball/

i'm bad at this Game

Did you created a group Dock ? perhaps i can beat you

Graham, maybe that's Windows security thinking it knows better than 
you, like Vista eating AltME's files?

The nice part is playing live against ~2000 other players (with realtime 
classification between players).

My best score is 120.

Wow, you're good

stucked at 1000 more or less

I'm not even in the top 100. ;-)

Rebol group
http://www.onlinegames.com/basketball/?2oisqn74tz

Won't work on Linux

Steeve: "Due to server load private Group Contests have temporarily 
been disabled (sorry)"

Graham: I've upgraded Cheyenne in SVN with an improved logging of 
translated filename from URL. That should help you see what's going 
wrong.