World: r3wp

if the ORM objects persist outside the database, you end up with 
a lot of complex state management and it slows down the database 
in real world examples.

its very hard to build the more complex systems outside the DB.


views are an abstraction too, but they are managed within the  DB, 
so there its more optimized.

same for stored procs.

Well, I aim for a thin and simple layer (probably using blocks rather 
than objects). If it became too complex or too slow, I won't push 
it further away.

I build my datasets as named associations rather than relations. 
  there is no relation in the data tables.  a completely generic 
and the most powerfull data model.

Does anyone have an idea why app-init.r from webapp on one virtual 
host seems to be executing on the other virtual host /requiring files 
that don't exist there, etc..

this happens on linux vps, doesn't happen on local windows

app-init.r callbacks from site-assistant (which I ported to 0919) 
execute in the other virtualhost / webapp

ah, found it.. I had an error in app-init.r (missing .so library)

-- the .so file missing was another problem but now I saw it still 
works like that. Now that .so it there.. after I restart, if I go 
on webapp af virtual host A first then I see at B that it runs A's 
app-init.r , if I go to the v.h. B birst , then A will report errors 
because it will run B's app-init

I didn't see this locally because locally I don't use virtual host, 
but just default

anyone using cheyenne with webapps / app-init.r and virtualhosts 
at the same time?

Yes, but all my app-init.r are the same for each virtual host.

My recollection is that I had some initializing variables in app-init.r 
but ...they crossed vritual hosts.  So, I removed them and placed 
them into rsp files instead.

Ie. I was seeing a similar bug.

I have different app-inits, one loads mysql other sqlite, sets different 
session keys, loads app specific modules

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.