World: r3wp

@Doc: 

- I am not totally sure I correctly understand what you mean about 
webapp. I will need to process and try it some more.

- 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. 
I intend to set it on     on-application start when fully in production 
(But I have to admit the server is bgehaving really fast even with 
this setup all along)
- good catch, I will remove one simpauth.r

- I am aware of hosts file, but so far decided to edit the cfg file 
each time I switch ... which is in retrospect getting a little tiresome 
with more and more apps so I should think of  some naming convention 
for getting to all domains local and do it that way yes

- great for multi instance support . I also already ported site-assistant 
to 0919. it was much less work than I thought.. mostly just few things 
like do -> do/global and some 3 other tricks (no really aplication 
level changes were needed)

Thanks for replies :) .. I will think some more about app-init.r 
and what you told and then send you the concrete example

and I will recreate multiple virtual hosts on local also before so 
I see how it works here

(I sent you email with files and video)

Janko, about the app-init code you've uploaded, just a side note 
: you're loading a *lot* of code (libs?) on each RSP request, this 
is surely slowing down each request a lot. You should be loading 
all these libs in 'on-application-start instead.

 or you can add them in the httpd.cfg in a worker-libs block, look 
 in Cheyenne/changelog.txt for 'worker-libs'

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.