AltME groups: search

hmm... how can i map a directory under a certain path in vhost? im 
trying this:
yp [  root-dir %~/p/ob/yp  alias "/public" %../public/ ]

then for curl http://yp:8080/public/angular-0.9.15.min.js  i get

HTTP/1.1 301 Moved Permanently
Location: /public/angular-0.9.15.min.js/

wtf?

i remember seeing something like "/some/path" [ options ] in a vhost 
config block, but i can't find anything about it now

i did a
~/p/ob/yp $ ln -s ../public public

as a workaround, but how can i achieve the same from the config file?

I use my own app platform, which is based on a pervasive templating 
system

It depends on the definition, but that's the direction I'm moving 
in. The structure is roughly MVC, and I have a method of updating 
web pages without the browser having to know what it means

Try REBOL is the first dynamic site I've done that way. You stay 
on the same page, send in data to a service interface and get data 
back that updates arbitrary parts of the page

Obviously it's nice to be independent from the server - if you can 
get it to work cross-browser. But I always thought we have View for 
that. Also, it seems nice to have the browser do input checking, 
but if you want a robust app, you will have to get the server to 
guard its own consistency and end up writing all input checking twice

In general, I notice that almost all web platform projects (and operating 
system projects for that matter) are either very focused on the server, 
or very focused on the client, apparently depending on the preference 
and abilities of the founders. This doesn't make sense to me: a network 
app by definition needs to deal with both sides of the connection, 
and find the best balance

i wish rebol/view was that good to replace the browser, but im typing 
this on a mac w ugly, aliased, miniature fonts and i can't even use 
the maximize button because it fucks up the screen size and layout...

angularjs is surprisingly backward compatible, btw... but serverside 
validation is still a must of course.

in this particular project we tried view, btw, but we need it on 
a tablet later in a warehouse, so /view is not an option at the end 
:(

AngularJS specifies a minimum of IE6, and IE7 for CSS, and no word 
about Opera and less popular browser engines. My system works from 
IE5 on (anything with AJAX)

Why wouldn't you be able to run View on a tablet?

No idea, but there are many now, so there must be a number of choices 
for the price of an iPad

im loading libraries from on-application-start, then i was hoping 
to load some static data too, but the words i assign there can't 
be found in my script later.

the script is called via an alias though which was specified within 
a webapp section.

on-application-start: does [
do %some/lib.r
db: %db/dir/some/where/
]

httpd.cfg:
vhost [
  webapp [
    alias "/xxx" "db.r"
  ]
]


db.r can't access the db variable, although it can use the words 
defined in the library loaded by 'do

wow!!!! there was an extra closing bracket before the end of the 
script and it completely derailed processing and i got back the script 
source itself as a response

Can you send me a minimal version of your script producing this error? 
I would like to see how it can affect the internal code so deeply.

I got it but was busy with other tasks. Will look into it in a few 
minutes.

confirmed: my script works w r135 but not w r136 (this is a different 
script)

hmm... it's a .r file but it's in rsp format, so no rebol header 
but <% %> tags.
so i guess it's the right behaviour

if i was calling the script .rsp and also bind-extern .rsp to the 
RSP handler then it worked too.

is it something hardwired in cheyenne, if the extension is .r then 
is should be handled as a plain rebol script?

s it something hardwired in cheyenne, if the extension is .r then 
is should be handled as a plain rebol script?

 Yes, .r scripts are processed as plain REBOL scripts but with the 
 addition of the whole RSP API since r100 (http://code.google.com/p/cheyenne-server/source/detail?r=100).


It has been officialy documented on the wiki only recently: http://cheyenne-server.org/wiki/Rsp/Basis
("No-template scripts" section).

Doc, did you get a chance to debug fast-rebol-cgi?

we have even experienced very strange behaviour with the
unless value? 'some-func [ do %../lib/obj.r  do %../lib/oid.r ]

tactic. our to-object function defined in obj.r didnt have a value.

we modified the script, did not restart cheyenne and it started working!

onetom: They should be just served as a static resource if the 'bind-extern 
directive is not used.

Kaj: I've pushed a fix in r137 for fast-rebol-cgi. It was wrongly 
defined as a Globals section keyword instead of a Host section one.

By the way, I still want to get rid of the loading of the REBOL CGI 
script on each request, even though I've minimised its size. It's 
a fallback script that now executes in the not-found handler. If 
I would change it from a fast-rebol-cgi script to an .r script, and 
put it in an ALIAS handler, would that preempt the loading of the 
script one each request? I'm not using the RSP interface, so the 
loading of that would be extra overhead. Would it still be faster 
than loading the small fast-rebol-cgi script?

Oh, I thought I was the amateur. :-) Maybe a night sleep will enable 
you to answer it?

If I would change it from a fast-rebol-cgi script to an .r script

 I understand you want to use the RSP handler instead of the CGI handler?

So do you think preparing the RSP interface for each request would 
still be faster than reading a small rebol-fast-cgi file every request?

i was moving a plain .r script which was aliased in a vhost context 
under a webapp and it started to fail because the 'do didn't seem 
to work properly

REBOL []  do %../lib/obj.r  probe to-object [a: 1]

obj.r defines to-object but i get a
        ** Script Error : to-object has no value

i moved the library stuff into on-application-start, but still it 
wasted me a lot of time to realize that the 'do is overwritten in 
RSP and works specially (as in, it does not work) in webapp context

what exactly is the purpose of the overwritten 'do function in the 
RSP handler?
 Bind the loaded code to a special per-webapp context.

A webapp execution context is isolated as much as possible from the 
rest of the vhost.

looks like u r using a parameter as a local variable

I thought I've added a note about DO having special effect in RSP 
scripts, but I can't find any mention in the wiki.

ChangeLog: yes, you should find it mentioned there. I need to add 
a proper entry in the wiki about that anyway.

Kaj: im just saying, it's a bit misleading to use an input parameter 
later as a temp variable in an other meaning

do/global works, btw, however a plain 'do fails very interestingly 
and reproducably

REBOL []  do %../lib/obj.r  probe to-object [a: 1]

this is my test.r file and im calling it from a webapp

from the root of a webapp

i want cheyenne to be less sucky, really. it's one of the nicest 
rebol projects and it's a shame if i can break it every second day... 
makes me not very proud of it... :/

Also, about using plain REBOL scripts in RSP engine, it was a last 
year request from Carl, it wasn't part of my planned feature list 
to support, so it can cause new issues that I have not forseen when 
building the RSP engine. You are the first one to report me issues 
with such scripts, so I guess nobody except you and Carl are using 
this approach. Anyway, your reports are helping me make it more reliable.

until yesterday the very same script was within <% %> tags actually 
and this effect was still observable.

just the latest svn version didn't accept the tags in a .r file anymore, 
that's why im showing it as a REBOL[] script.

otherwise, i was just following common sense and trying to get things 
done in an ultra primitive way :)

the script worked and still works as a CGI script btw, so i bravely 
switched over to the RSP handler as it's been suggested on the "Basics" 
documentation page and i was using the very same unless value? 'my-object 
pattern to load my libs.

what does "run Cheyenne with a non-persistent? worker." mean, btw? 
-w 0?

It works here in a vhost (not in a webapp) using:

%obj.r  => REBOL [] to-object: func [a [block!]][context a]
%test.r => REBOL []  do %../libs/obj.r  probe to-object [a: 1]

Testing within a webapp now...

>> read http://localhost/test.r
== "make object! [^/    a: 1^/]"

From a webapp, it works ok too:

%libs/obj.r  => REBOL [] to-object: func [a [block!]][context a]

%www/testapp/test.r => REBOL []  do %../libs/obj.r  probe to-object 
[a: 1]

>> read http://localhost/testapp/test.r
== "make object! [^/    a: 1^/]"

I have disabled the 'auth keyword from /testapp webapp to do this 
test, to avoid being redirected to a login page.

I have run the tests using -w 1, using -w 0, I get a "to-object has 
no value" error.

So, now I load the db from a disk file each time ...

I have mutiple users using a web app on different ports.  Each has 
their own vhost, and their own pages but to keep things simple, each 
web app is the same.  I include a config file each time a rsp page 
is loaded with the db definition instead of in the app-init.r where 
it did not work

Kaj: pushed a fix for that in r139.

I've checked that I'm doing everything right according to the latest 
Cheyenne conventions. I have a fairly standard httpd.cfg with this:

Odd, maybe a regression in the latest revisions...I will test that 
on my local linux box in a few minutes.

This is a custom Linux, so no comparison to Ubuntu :-)

One difference is that the root user and group are called "system", 
but I didn't find a problem with that in my Cheyenne patch a year 
ago

Could you extract the mod-userdir/get-id function and try to run 
it from a REBOL console using:

    col: #":"
    get-id "www"

I have found a bug with the 'chown function.

Ok, I think it is not needed anymore. It seems that the set-gid call 
is failing on your system for group "www". Set-gid returns a logic! 
or none! value if running on a 2.7.8 kernel and an integer! for previous 
kernels (due to different mappings), that is what's causing the error.

If only Carl has freed /Library on Linux instead of adding 'access-os 
native...it would have saved me a lot of coding/debugging time...

Kaj: I have pushed a fix (needs testing).

Means a 30x HTTP code was returned by the request.

needless to say i've created both app-init.r files for the sake of 
the experiment w a content of REBOL[] but im still getting the error

Have you tried to define a webapp inside another webapp?

any example how do u test pages behind a session?

im trying curl -D- -d 'login=test&pass=letmein' -c jar http://localhost:8080/app/login.rsp

but subsequent curl -D- -c jar http://localhost:8080/app/some.html 
still gives me 302 to login.rsp

any example how do u test pages behind a session?

 You shouldn't use AUTH keyword if you don't want the redirection 
 to a login page.

i'd be interested in looking into the sessions during runtime too.. 
can i do it on the cheyenne console by pressing escape?
You can access them in 3 different ways:


1) if run from sources, escape in the console, then enter: probe 
uniserve/services/httpd/mod-list/mod-rsp/sessions/queue. Type do-event 
when you want to resume Cheyenne.


2) run the %clients/rconsole.r from the source archive, you will 
have a remote console connected to your local Cheyenne process (try 
on prompt: netstat)


3) add this to the config file in globals section: persist [sessions]. 
When you want to look to the sessions, just stop Cheyenne process, 
a .rsp-sessions file is created holding the session objects.

it maintains cookies in a jar

thats what im not sure how to handle w a little code in rebol, that's 
why i was asking u; thought u need have some examples in ur toolbox

You should try to send a GET request first on the login.rsp page.

so it's worth learning.

i was a wget user earlier, but since macs come w curl and i can easily 
apt-get install curl and even syllable comes w curl, i don't give 
a fuck anymore how an inefficient bloatware is curl, im still trying 
to use it and only it :)

my-http is nice though. i wish there would be a guide for all these 
protocol extensions.. there are a couple of half-baked versions of 
them... :/

it's actually available for a lot more platforms than rebol nowadays

u know if rebol would come w a nicer header dump, cookie, https and 
url encode/decode support by default, i would advocate it as a curl 
replacement probably... :/

maybe an extension script would be enough, which anyone can remember, 
like http://json.org/json.r

pff.. my-http is not really transparent...

>> do http://www.rebol.org/download-a-script.r?script-name=my-http.r

connecting to: www.rebol.orgScript: "patched HTTP/HTTPS protocol 
with cookies support" (18-Aug-2006)
== none
>> trace/net on
>> read http://localhost:8080/testapp/login.rsp

URL Parse: none none localhost none testapp/ login.rsp** Script Error: 
querying has no value
** Near: http-command: either querying ["HEAD"] ["GET"]

btw, let me micro-interview you here: why the hell are u still using 
windows!? especially for development? :)


I consider that GUI are an improvement over CLI that make my life 
easier and computers simpler and more fun to use. I stick with Windows 
as my main platform because I never got used to Mac OS UI (tried 
for a few weeks, but gave up rapidly) and I found the other UNIX 
GUI less "efficient" than Windows. Also I found Windows to be quite 
transparent for my work, it just doesn't get in my way as other OSes 
tend to do, so I can focus on my work and forgot about the rest (especially 
since Vista days, I am now a very happy Seven user).


I must also add that I was an Amiga and BeOS user for more than a 
decade and spent all my college days on AIX, X-Windows and SunOS.

:) thanks. interesting.

i was doing DOS, TurboVision, then tried Win3.0. used Turbo Pascal 
in 2 dos windows under Win3.1, programmed serial equipement with 
Delphi 1.0 under Win95, but then i just fell in love w the fvwm2 
theme of icewm and the big virtual desktop which even worked on trident 
8900 isa cards, using suse linux. i was forced using windows until 
the xp version and i even saw delphi 4.0.

no windows interface can compete with icewm with autofocus and saying 
this as someone who still can handle windows without a mouse faster 
than anyone else i know.

i found vista and win7 particularly disgusting. those dim windows 
w huge decorations just make me annoyed.
im the fullscreen terminal window in black&green kinda guy :)

i want console in web browsers too. i think lisp machines were great 
examples that how the character based interface can benefit from 
graphical capabilities.

plan9's acme is also a nice example; although i never had the chance 
to use it for anything real. never really seen an expert using it 
either...

No, it a browser thing (unless you can disable it in your web browser).

Cheyenne uses volatile cookies (with HttpOnly attribut) that are 
safe for holding a session key.

hmhm... the auth directive is not completely useful for me, because 
probably i shouldn't return a 302 to the login page when the session 
of my json service times out... :/

To produce the logs, Cheyenne needs write access to the folder with 
the configuration file and (future) logs. This becomes a problem 
when it gives up its root capabilities, and the mechanism to adapt 
the privileges of the log files still doesn't seem to work

When Cheyenne has access to this directory, but only for reading, 
it quits silently. -vvvv doesn't even provide a clue what went wrong

When it gets write access, it produces a crash.log under the new 
user name, showing that it switched. But it had already produced 
a normal log under the root name, and doesn't adapt its ownership. 
This is indeed what the crash.log then warns about

This is both against the structure of Unix and modern Windows systems.


UNIX filesystem layout usage are not identical. Here are the Apache 
error log location in just 3 UNIX flavours (among dozens):

* RHEL / Red Hat / CentOS / Fedora Linux Apache error file location 
- /var/log/httpd/error_log

* Debian / Ubuntu Linux Apache error log file location - /var/log/apache2/error.log

* FreeBSD Apache error log file location - /var/log/httpd-error.log

and here are the possible locations of configuration file:
* /usr/local/etc/apache22/httpd.conf
* /etc/apache2/apache2.conf
* /etc/httpd/conf/httpd.conf


Notice how the file name changes too (both for the log and conf files). 
BTW, I personnally prefer the GoboLinux approach ;-).


One the Windows front, it is barely better. The registry database 
is fine for storing parameters (name/value couples), but not a REBOL 
dialect file. A common way is to store files created at runtime in 
%USER%/AppData/Local/<appname>/. Cheyenne stores all his files (including 
config file) either in the local folder or in %ALL_USERS%/Cheyenne/. 
Storing them in %USER% hierarchy should be better.


Taking into account every OS specificities (or oddities) is not always 
a good choice for a cross-platform product. I know that Cheyenne 
needs to be gentle with the OS best practices, so I am willing to 
improve it whenever it is possible, but without sacrificing the default 
behaviour (because that is the way I want it to work for me).


BTW, I am also willing to test the centralized logging approach, 
but it has to be a cross-platform solution. So an abstraction layer 
needs to be built with connectors for UNIX syslog daemon and Windows 
Event Logger (they are two types to support: pre-Vista system and 
new Vista/7 one). Has anyone already worked on such wrappers with 
REBOL?


I personnaly need that the log files be exactly in the same format 
and if possible at the same place across platforms to make my life 
easier, so this will keep being the default anyway. The current -f 
internal Cheyenne command line (Windows specific currently) could 
be extended to work on UNIX too (and no Max, this one cannot go into 
the config file, because it indicates where the config file is located 
;-)).

- User data. The websites. May be segmented over multiple user accounts 
or a global area

As I understand it, this looks like Cheyenne will need a per-UNIX 
system install script? Or will we let users spread the files acrosse 
the filesystem as they want and use options to redirect properly 
each file classes to the right folders?

A clear way to set the path to the UniServe library in the source 
version would also be good. I patched the Cheyenne source for that 
so far

You mean when running %cheyenne.r from a remote location?

Structure of a package:

It is absolutely not simple:
- Cheyenne binaries use a memory-based virtual file system.

- When run from sources, files internal relative paths depends on 
where the REBOL binary is run from.

- REBOL on Windows has 2 different working folders (one for REBOL, 
one for the system), while on UNIX, it seems that there is only one 
(from the REBOL POV).


Make a cross product of items and you'll have all possible combinations 
to manage.

I would like to take this opportunity to clean up things and hide 
the low-level mess under a unique abstraction layer.

I think I will make a new virtual filesystem for Cheyenne that will 
abstract all files accesses (including web sites). This would have 
the additional benefit of allowing to encap web sites files too (a 
feature I wanted to have since a long time).

This is quite a big change, so will need several steps to complete. 
I will first just patch the current way to allow relocating config 
and error files for UNIX users.

can we start out with a documentation / sample implementation 1st, 
please?

it sounds like a project which can be very well reused in other cases 
too.


i've outlined the mentioned directory areas here: http://piratepad.net/KkvkZ9AtME

Thanks for the summary. I need to study every cases first anyway 
and find a clean and simple way to implement it. My first idea would 
be to use a custom scheme for that, like vfs:// that would resolve 
all virtual paths transparently.

Yes, but it is a very basic one and you need to use custom function 
calls, like: do-cache, load-cache, read-cache....

Kaj: I have pushed a fix for the verbose mode making Cheyenne crash 
when running as none-root. It works well here on my Linux box. Let 
me know if you have other issues (locally generated files issue aside).