World: r3wp

My impression was that app-init is not isolated from other virtual 
hosts

and other web apps

Dunno about app-init, but on 0.9.18 my logs seem to mix up accesses 
to different virtual hosts

Kaj, about logs that has been fixed a couple months ago, I can only 
suggest you all run latest svn

Janko, I have many app-init.r and do not see any problem, if you 
sand me your app-init from both virtual host and tell me exacltly 
what is the problem you are seeing, I'll be glad to check that

maybe I should download from svn too then. Just some do/global and 
session/add. I tested many times and I can clearly see that whichever 
I visit first after restart becomes "global" and runs also in webapp 
on different v-host. I will try with svn version and report. Maybe 
this problem and problem with logs are related and were both solved 
back then.

http://paste.factorcode.org/paste?id=1069~ here it is

hm, the tabs got confused

Janko: webapps are per Cheyenne instance, not per virtual host. What 
is specific to a virtual host : webapp virtual path and other config 
options. I'm not sure to understand how you've configured your (or 
yours?) webapp(s). You can send me your virtual hosts config privately 
so I can see what's your need.

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.

Kaj: the bug you're referring to has been fixed in v0.9.19 released 
on 1st march 2009. Time to upgrade. ;-)

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. (btw, "simpauth.r" 
is loaded twice)


About local testing, you can use virtual hosts locally too in Windows 
easily. Just add them to C:\Windows\System32\drivers\etc\hosts file. 
Add them all after 127.0.0.1 (but do not use exactly the same domain 
name as the remote ones or you won't be able to access them anymore). 
I use shortcuts of my real domains for locals : softinnov.org => 
si.org, curecode.org => cc.org, etc...

About multiple Cheyenne instances running at the same time, I'm finishing 
a new version supporting that feature. It took me more time that 
I thought first due to additional OS specific code required (wasted 
a lot of time on OS X). Still a few minor things to fix, tweak and 
test. It should be available by tomorrow.

@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 ;-)