World: r3wp

yes, always so it should have write privs

this is the problem I have after restarting ubuntu
http://screencast.com/t/NDgyYzBlM

going to copy the .cache.efs file to cache.efs and then copy it back 
each time with a shell script to see if that fixes it

That's odd; with regular Unix file permissions, the only way you 
could not have access as super user is if the file is read-only, 
but cache and log files would be unlikely to be that

I can write the .cache.efs file as sudo in rebol, but no sudo in 
cheyenne.  Bizarre huh?

Are you switching the user account in the Cheyenne config file?

Also, in the screencast you're starting Cheyenne when it is already 
running, so it may be a legitimate fille locking error

No and I'm not.

After the first pwd you see that I get a message to say that my process 
was stopped.

I then do a ps aux | grep cheyenne to confirm that it is no longer 
running

Any harsh protection subsystems running on that Ubuntu besides the 
traditional Unix file security?

Nope. This is a new ubuntu default installation.  I am *presuming* 
cheyenne quits because it can't write the .cache.efs file  but don't 
know for sure

running cheyenne in verbose mode doesn't help because it never gets 
to start logging the error

Ubuntu has had extra security subsystems for several years, though. 
Probably SE-Linux - I'm not very familiar with it

Well, I don't know what is going on but hopefully my saving a copy 
of the .cache.efs file and copying it anew each time the user restarts 
cheyenne will bypass this issue

After rebooting OSX, I'm now getting this error, when trying to start 
cheyenne.r:

make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'context
    arg2: 'blk
    arg3: [block!]
    near: [extension-class: context list]
    where: func [/local list][
        list: extract phases 2 
        forall list [change list to-set-word list/1] 
        repend list [to-set-word 'service none] 
        extension-class: context list
    ]
]

It's an older cheyenne 0.9.17.

found the bug. it seems that cheyenne 0.9.17 cannot run with rebol/core 
2.7.7 due to it's inability to make a context from a hash!.

I'm running Cheyenne on 2.7.7 now, so I can confirm that new Cheyenne 
versions run there

this is in fact a bit odd... I've been running cheyenne on this machine 
for about 18 months without modifications and suddenly it would not 
run unless I changed the 'phases hash to a block in httpd.r.

I think HASH has been changed by the R3 Forward contributions

Or doesn't that make sense? It would be MAP, of course

No R2/Forward changes wold cause that.

I found this on multi-tenanting http://msdn.microsoft.com/en-us/library/aa479086.aspx

I adopted the isolated approach with separate DBs for each user, 
and separate webapps for each user .. but I think it's just not efficient.

Just wondering if do-sql protects against SQL injection ...

It supports Prepared Statements (Parameterized Queries) which I think 
are bullet proff of I think (at least) because they are done with 
database. Theory is that if you do it in code there can be edge cases 
where db will interpret stuff differently as you quote / escape it 
so that is not good.

do-sql 'db [ "select * where id = ?" id ]

what do you mean by separate web-apps?

http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29

I use isolated approach too, but I use sqlite databases which are 
not that good for webapps but ok for isolated since 1 user wont make 
hundrets of connections to the same database at the same time

and sqlite databases are just files so you can have them as many 
as you can stuff on your disc :)

Ok, good to know ..never seen it discussed before.

Looking like the next mobile Safari will support websockets... pushing 
Cheyenne generated data to the iphone sound intriguing.

It should: WebSockets have been in the WebKit development builds 
for a while. So all the other WebKit-based browsers should get it 
soon, too

I have an ongoing issue with cheyenne websockets when not using port 
80 (?) the page loads, the socket connects, but immediately disconnects?

the browser disconnects (dropped an alert in the ws.onclose function) 
but there's no disconnect message from Cheyenne?

Actually, not quite.  It's not working when connecting from the machine 
that's running Cheyenne (windows 7), but connects fine from an xp 
box on the same network.

You're running cheyenne on port 80 under windows 7?

Hi Terry, it's possible that the ws URL wth port <> 80 returned by 
Cheyenne doesn't match the one expected by the browser to validate 
the ws handshake, let me have a look at it...

port 82

Terry, it doesn't look like port-related.

I think its some weird Windows 7 thing.

What URL do you use for your ws connection in JS code?

I've tried everything.. now im using the  FQDN including port :82

Can you show me the URL?

Do you change the hostname dynamically in the ws URL or is it static?

static

it's in your user group

if it's static, then it can work only for the URL you've written, 
so from the server itself, the URL might be invalid