World: r3wp

HAHA, looks like osx is a time waster, for Dock but for Carl as well 
8-)

Me I suggest something like domain.lan or domain.local for local 
testing

Maxim your associative datasets are in memory or in disk, are you 
using any index or simply search thru dataset?

Will: good suggestion, local domains extensions are not restricted. 
I like the .lan :-).

Janko: I'll give it a deep look today.

Cool, thanks Doc. I didn't report it because I'm on an older version. 
It works OK for the rest, so no rush to upgrade yet

think built-in JSON support, COMET, etc
Comet is dead.. look into Websockets

SVN r42 : mutiple Cheyenne instances now supported. Please test it 
fully before putting in production.

OS X version not tested but should run ok.

Seriously, if you jump on the websocket server protocol, you can 
quickly promote Cheyenne to the masses.. but if you wait, you'll 
lose the window of opportunity.

Cheyenne is not ready for the "masses" yet. No docs, no UI for config 
options,...

by "masses" i mean the geeks

web sockets are an HTML 5 spec

I imagine you could build a web socket protocol with Cheyenne in 
a few hours.. would take me a week

the protocol, by the way, is ws:// or wss:// for SSL

Apache already supports web sockets using a python plugin : http://code.google.com/p/pywebsocket

Yeah, I've played with it. It's cumbersome.

Here's the W3C Web Sockets API if you're feeling so inclined. 
http://dev.w3.org/html5/websockets/#the-websocket-interface

Not sure if you recall, but the work I was doing with Cheyenne was 
trying to implement  Web sockets before Web sockets even existed.

I think you described it as "no longer HTTP" or something to that 
effect :)

I'm having a quick look at the ws protocol, just curious to see how 
it has been designed.

The problem I've always had with Cheyene and Uniserve services was 
the 'disconnect' between the two.. ie: having a uniserve 'socket' 
connect with an 'http' connection and vice-versa.  The ws:// protocol 
was what i was looking for.. the best of both worlds. Deliver some 
hypertext, then push data to javascript in the browser.

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

Cheyenne is already doing such kind of "connections", for example, 
PHP requests : HTTP => Cheyenne => TCP => PHP server.

Thanks for the PHP server script...looks pretty simple to implement.

Yeah, it seems like a no-brainer for Cheyenne to easily implement 
this new protocol... at least for a Cheyenne guru.

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