World: r3wp

yes, if it will work it will be very good too.. sooner or later one 
might need somethig like that

I'll have some free time from now 'til the beggining of next year 
that I intend to devote mainly to Cheyenne and CureCode, and if time 
permits, on some new frameworks.

my wishlist is solving the compression error wher error happens (probably 
harder) and additional option for debug where I could see error output 
in browser like in debug but there would be no debug toolbar (probably 
simple) :))

and option to globablly in conf file set compression off maybe

none of this is urgent.. just few ideas from a happy user :)

Compression error when error happens

 : that one is solved in 0.9.20 (current development version), see 
 ChangeLog.

oh great!

improved debugging : on my todo list. I might try to emit the debug 
info to a JS console like Firebug's one or a custom one.

aha, that would be cool , I use firebug too

and most webdews should if they don't

Just for teasing, I've prototyped a Hibernate-like layer for REBOL, 
just read-only for now (only issuing SELECT queries). I'd like to 
push that prototype further to have a complete database abstraction 
layer with object (or blocks) to relational mapping abilities. The 
goal is to kiss goodbye to SQL (for most operations) and be database 
agnostic (the database drivers would have to conform to a specific 
interface, probably the one used by mysql:// and RT db drivers).

interesting .. I specifically am otherwise not the ORM fan , but 
so far I am almost the only one I know (except Maxim) and I talked 
to a lot of people about it :)

so this will  be a good feature to many

I'm not a big fan too, but I can't deny the advantages it gives to 
query an abstracted hierarchical data model instead of the physical 
relational model. The bigger the project, the more gain you get. 
For some cases, you still need to go down to SQL thought.

its just an abstraction layer.  whatever form it takes has advantages 
and disadvantages.

Right, but the higher the abstraction, the more productive you're 
supposed to become.

Last but not least, I'm also actively working on Cheyenne's Control 
Panel. I'm giving a try to ExtJS for the UI. This would both get 
us a very nice looking Control Panel, and help me optimize Cheyenne 
for AJAX RIA apps (think built-in JSON support, COMET, etc...).

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'