World: r3wp

ok, this was not a problem running as a service, but cheyenne.exe 
did not start at all, as it could not find some Uniserve modules.
After adding adding all of them to the cache, it works again.

.cache.efs may have been too old. It is refreshed when you start 
Cheyenne from sources. As a rule of thumb : boot Cheyenne in source 
mode to refresh the encap cache definitions before encapping (especially 
if you did a SVN update).

Thanks,

Cheyenne is really one of the Rebol programs, I use without any own 
modifications.

could there be any problem with running two cheyennes on different 
http ports on same computer ?

well, I am quite sure not this is the problem, I thought before that 
the problem was with accepting the port for ex. 8080 but now I put 
nginx in front which will send requests to each othe them depending 
on the virtual host ... but it's the same, one one runs the other 
can't run. Could this be because they use same ports for workers 
or something like that?

not = now

You can't run two Cheyennes on the same PC without some issues.

the logging won't work properly .. I think both will be logged by 
one instead of each having their own logs.

Doc has said he will fix it .. but I doubt it's a priority.

I could live with loging , it's a somewhat temporary solution .. 
but here the second cheyenne crashes

Well, I don't think it serves properly either ...

The workers depend on task-master service which will change it's 
listening port number if run on port <> 80. So no issue with workers. 
But others services have been added like RConsole, MTA and Logger 
which are not "multi-instances safe" yet.

I want to run another webapp on vps where I have site-assistant on. 
but site assistant is written in older version of cheyenne and I 
don't have time to port it to latest right now. that's why I am doing 
this

(and this new app is written in latest) .. maybe I should try to 
port it.. can't take taht much time

Logger service is for debugging messages btw, it doesn't handle HTTP 
logs.

Oh yeah ... it was trace.log I was thinking of.

I don't think I managed to get two Cheyennes working at the same 
time properly.

I used to run several Cheyenne instance on linux server but it was 
a long time ago (v0.9.15 or 16). I didn't do much testing on that 
use case since then.

I am using debian .. I will port s-a to new one .. probably won't 
be that many changes, only problem is testing it all again and being 
sure it works ok ..

and I was so proud how I solved the problem with nginx :)

I'll have a look this weekend on this issue to see if I can get a 
quick fix (it wasn't simple last time I've checked, but the cold 
freezing wind blowing out here these days might help my brain be 
better irrigated ;-)).

IIRC, having multiple instances on Windows was significantly harder 
than on UNIX platforms. I'll run a full testing on that issue tomorrow 
to get a better picture.

you don't have to for my specific case, I am already porting ... 
I would have to sooner or later

It needs to be fixed anyway. I, sometimes, also may have needs to 
run different Cheyenne versions on the same production server at 
the same time. Graham also has needs for this, so I think it's time 
to settle this issue once and for all.

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