AltME groups: search

Btw, you can see a nicely formatted diff of all the changes here 
: http://code.google.com/p/cheyenne-server/source/detail?r=30
(click on [+] to see the changes)

I'm just trying to do a file upload using RSP ... see http://rebol.wik.is/Cheyenne/Upload-file.rsp

If the post data is over a certain size, it gets put in a temporary 
file that you can read.

Yes. It's probably to cut down on interprocess communication between 
the host and worker processes. The RSP is processed in a different 
process than the web server process.

I'd have to look it up. Give me a sec.

I have a need for users to "sign" PDFs using a tablet ...

Jarnal is an open source Java app that can ink on PDFs and save them 
back to the server by posting the PDF with the annotations to a cgi 
script.

It can also save the first page of the PDF as a Jpg, and interestingly 
the PDFs are about 12kb in size but the Jpegs are about 150kbs

but the reduced size advantage of the pdf is disadvantaged by the 
time it takes to recreate the PDF .. ie. saving it as a jpeg is faster.

Adding support for that shouldn't be difficult, but how to efficiently 
and securely manage the associations between user/pass and access 
rights? I'm not a big fan of .htaccess files scattered everywhere, 
and I'm not sure that cluttering the httpd.cfg file is much better. 
Maybe a separated centralized config file for user accesses? (I need 
to dig more on this topic before starting any implementation)

I'm about to build a user login system, but I would like to know 
if it's a good idea to make this a public project so others can follow 
and contribute? Would it be a good idea to include it in Cheyenne? 
I don't intend to use MySQL for it as the rest of my site isn't DB 
driven.


I've not done anything yet, so I also need to know, what Cheyenne 
can already do in this area, to avoid duplicating functionality. 
Can I completely rely on the session context, or are there crucial 
parts missing?

Well it depends on what you mean precisely with "user login system". 
Sessions associate a context (in the general sense) holding data 
with a remote web browser session. The AUTH config keyword controls 
whether access to webapps resources requires a "login" process or 
not. The login state is reflected in a built-in special word in RSP's 
sessions (session/content/login?). LOGIN? is also settable, so you 
can avoid using AUTH and build your own login system (you'll have 
to overload the 'on-page-start handler to restrict accesses).

You need to setup a memcached server first I guess. Will has implemented 
something similar as a cheyenne mod. I may integrate such feature 
inside Cheyenne in future.

Doc, thanks.

What I need to do is basically the whole package:

Sessions, which Cheyenne can do.
Login process with authentication. AUTH config, perhaps.
Log out process, also possible.
User adding and removal process. This needs to be added.
Privilege usage and management. Also added separately.

I'll have a closer look at the built-in AUTH config keyword.

It's a uniserve service with an rsp interfaces, works pretty well, 
if something takes more than 1 millisecond to execute, better cache 
and reuse 8)
interface is simple:

.cache 'pool-name 'variable-name 'valid-time-in-seconds [code to 
execute]
one refinement, /set , will force update cache

Available to a number of servers?

I have the latest svn checkout ... I don't see a cache.r  !

I use Cheyenne as a helper application.  Now my main application 
occasionally has to access files from S3 but synchronously.  Since 
the s3 tools don't have async versions, does it make sense to perhaps 
to use RSP to download the S3 files I need.  I can call RSP async 
from my app.

Seems that I have a problem with session handling in that I don't 
get a new session when I expect it.

I use session/id as a filename to store some temporary data between 
requests. But it seems either that session/id is not that renadom 
or that a session somehow survives a long time.

How is a session managed? When is it created and when is it destoryed?

It seems that I somehow get back an old session/id from someone else 
even I just opened my browser and loaded a page.


This problem shows in my REST shopping cart in that I get a shopping 
cart from someone else.

The code handling this looks like:

; GET
startsession
 [
  unless session/active? [ session/start]

  if load-cart session/id [show-cart]
]

; POST
addtocart
 [
  ; do we have a browser session?
  either session/active? [
     load-cart session/id
     ....

When is session created?
 On first request to a webapp resource.

When is session destroyed?

 When you invoke session/end or once the session timeout period has 
 expired and the garbage collector has suppressed it. Not sure what 
 happens if you try to access it after the timeout before GC passing, 
 need to check it.

Ok, trying to access an expired session still in memory, will force 
it to be destroyed and a new one will be created instead (with a 
new ID).

But it seems that you're not using webapps, just plain RSP and manual 
session handling. You should know that invoking session/start container 
will create a new session context but you won't get a new ID at once 
(session/id will be set to none until the RSP page ends). We already 
discussed this point previously and I have an entry in my todo list 
to improve that. (it requires a change in the session ID creation 
process)

Let me know if it's an urgent need for you, I might do a quick change 
in the next revision to give you a workaround.

Graham: did you tried launching a new temporary REBOL process using 
LAUNCH or CALL for sending the requests to S3? (Did I understood 
correctly that your need is to access S3 asynchronously from your 
main application?)

doc, no I didn't as that would start up a new App process which seems 
excessive to just do a download ... especially when Cheyenne is already 
running in the background :)

I think I can just include the S3 libraries in the Cheyenne binary, 
and do a S3 download as a rsp form where I submit the filename, bucketname, 
and access keys

just thought I'd drop a little note that serious remark module work 
has begun.  I was trying some stuff before, but starting too wide 
and I wasn't able to get traction on the project.  now I'm just integrating 
the v2 remark parser into a mod.  


One cool thing that it will do out of the box, is handle statically 
parsed files. basically, you build .html files using remark dynamic 
tags, they are saved out in a cache dir and then the url-file function 
will redirect to the parsed file, if done, or will run the parser 
on it and then cache it.

I need to get my web sites up quickly for a few projects, so this 
is a priority thing... I expect to have the first few quality pages 
functioning within a week.


with a few REBOL projects (some still unheard of) to share with all 
of you guys on one of those sites.  :-)

Session: "On first request to a webapp resource." Hm... I'm not using 
a webapp, just a RSP file. Could this make any problems?

ID creation: My RSP file ends after the "startsession" for this case. 
So, only task here is to either re-use an existing ID or create a 
new one, that is used in all upcoming RSP calls. Hence, I think the 
logic is correct.

Doc, I think that the problem lies somehwere in the session terminating. 
It realy looks like session IDs somehow survive and are re-used even 
for a complete new session.

Could you make a minimal RSP script that shows the problem and send 
it to me?

You can use a shorter timeout period (e.g. 30 secs) to test behaviours 
when session timeouts.

doc, I've got some questions about http.cfg vhost redirection...

www.domain.com:81 [
	redirect 301 "/*" "http://www.domain.net"
]
www.domain.net:81 [
	root-dir %/E/dev/project/my-web/web/www.domain.com
	default %index.rmrk

]


should this work?  cause its not .  I'm still getting a request for 
domain.com and a 404 error.  domain.net works perfectly.   

actually, unless I include a root-dir entry in domain.com config, 
I get an error within cheyenne.

Root-dir is mandatory in a domain definition (even if you try to 
redirect everything to another domain).

I've added your virtual domains definition to my httpd.cfg file, 
added a root-dir to domain.com, added :81 to the redirection URL, 
mapped both domain to localhost, changed domain.net's root-dir to 
%www/testapp and it works ok :

>> read http://www.domain.com:81
connecting to: www.domain.com
connecting to: www.domain.net
== {<html>
<head>
^-<title>Welcome to TestApp web application</title>...

BIND associates a mod handler with one or more file extensions. For 
example:


o bind SSI to [.shtml .shtm] : process those extensions through mod-ssi.

o bind php-fcgi to [.php .php3 .php4] : process those extensions 
thru  mod-fastcgi using a php backend.


The ID value used as first argument of BIND is just a hook used by 
the target mod to know which request it should process (as required 
by config file). See mod-ssi.r as an example.

Those associations could have been hardcoded in each module, but 
BIND gives a more convenient way to define and maintain those associations 
than having to change mod-* source code.

ok cool... I'll add a new directive for remark which is bind-static, 
since it treats static and dynamic files differently.

the first release of mod-remark, next week, will not have a handler, 
but I will be working on that quickly after... in order to make the 
mod more scalable.

The choice between adding a mod (main process) or handler (worker 
process) is simple : when a mod function is evaluated, the server 
waits for it to complete before being able to process any other network 
event. :-)

mod-rsp is quite complex, it does a lot of things. You can start 
by mod-action (which handles CGI), it's like a stripped down version 
of mod-rsp (no session, no webapp, etc...) to get the basics of using 
an handler, then dive into mod-rsp to add higher level features.

handlers seem easy enough to setup, but then it opens up a few problems 
for session concurrency, and stuff, which you already know... so 
I want to iron out the whole dynamic remark architecture before tackling 
the performance issue.

I'll be adding session support and integrated forms creation within 
a few days...

It would be so much easier to implement and so much more efficient 
if we had multithreading and a way to share data between threads.

I am thinking of building a session server for remark. an uber simple 
multi-tcp port server which implements liquid-net and synchronises 
the remark handlers, in a lazy way.  so unless the users are actually 
calling for pages.... no network traffic occurs between processes.

Doc, I don't know a lot about this subject so sorry if I ask stupid 
questions :) ... could it be made and would cheyenne benefit from 
using IPC like pipes to communicate between processes instead of 
TCP ?
(I used pipes just once so far so I don't know much about them)

BTW.. did any of you see the recent discussions about Unicorn ( a 
pure Unix philosophy webserver - that uses pool of processes .. etc.. 
very interesting blogposts in any manner, I can find links if anyone 
is interested. It reminded me a little on cheyenne too, although 
Unicorn has no async I think)

janko yes, IPC is another way to approach the issue, but the question 
is how easy would it be to use within R2?  have you successfully 
done IPC stuff within REBOL using a dll?

Dialect: no, but you can have a look in %mod-static.r, there's a 
lot of examples there.

ok... with this info I've done a few tests and I see the config files 
allows you to dump pretty much any thing anywhere... is the  'in 
keyword only for the 'do to be recognized within one of the setup 
blocks?

ah just noticed a little "conf-parser" error line within the wealth 
of prints on startup  :-)  I see my previous statement isn't quite 
true  :-)   hehehe

if you're accepting ideas for cheyenne... it would be cool for the 
conf dialog to allow us to add items in the systray, which fork to 
a system event within the mod.  many uses for this come to my mind 
 :-)

can I get a login for cheyenne's website wiki?  I would love to help 
you out with the docs, as I build up my mod...

I'd use it to switch debug modes in real-time... and maybe even build 
a small view config/debug pane, if I detect a view version running 
cheyenne.

View debug panel: I thought about that too a while back, never had 
time to try that concept.

I'm adding a lot of debug options within the config file directives 
right now... would be nice to be able to give an interactive face 
to those options  :-)

View debug panel: definitely a useful tool.

ok I looked at web apps... remark is basically an uber web-app architecture... 
all it needs are a few more configs.
I'll add this in the second release of the mod

Max - never mind. If I want to use only Cheyenne, it is not a problem. 
I was thinking around the lines of producing rebol aproach, which 
would be interchangable easily between Apache and Cheyenne, for those 
who can't afford to push their provider to run Cheyenne for them. 
So I thought that following Apache equivalent would be useful. But 
my request surely is not a priority ....

AddHandler rebol-cgi-dispatch .html
Action rebol-cgi-dispatch /cgi-bin/rebol-cgi-dispatch.cgi

Max: thanks for the cheering up. :-) I've been also quite satisfied 
by the way Cheyenne evolved, a lot of thanks to patient users who 
report issues and propose fixes or new ideas. I wouldn't have got 
so far without community support!

Pekr: that's in my todo list, I just need to find some free time 
to think more deeply about how to support such feature efficiently.


Btw, I have built a XMLC (XML Compiler) engine inspired by enhydra 
(http://www.enhydra.org/tech/xmlc/index.html) which should fit perfectly 
your needs. It's a working prototype but need some significant work 
to be integrated within Cheyenne, so it's low priority for now.

well... the main call to remark is ... compile   hehehe...  I do 
plan on making an XML document model eventually.  basically, it would 
convert XML elements into your current Remark document models, so 
you can leverage the same code base but with another data model as 
input.


optionally you could build direct XML document models for a bit more 
speed.


all that needs to be done to make it easy for you guys is to build 
a few simple base XML tags which allow you to build the dialect based 
on xml element names.

And, I agree it's a very nice piece of software.

Only from close friends living in the java world, beyond them, no 
one. I don't expect much from outside REBOL world yet, Cheyenne is 
mainly useful for REBOL programmers. Once it reaches 1.x, Cheyenne 
will have features that would make it more interesting for outsiders 
(like a simple web control panel, web sites and webapp packaging 
in one unique executable, on-demand ready-to-use web application 
loading from our servers: blog, forum, bugtracker,...). I may also 
add a FTP service in a future 1.x version and a lot of other innovating 
new features I have in mind. ;-)

I'd like especially to make it a one-click solution for corporate 
users that need a blog, wiki, bug or task tracker,etc on LAN.

I honestly hope that remark can be a driving force for cheyenne btw... 
remark was never designed for rebolers.  the fact that its tightly 
integrated into html makes it very appealing for non-programmers, 
as well as the fact that it can use rebol's extremely rich datatype 
system.

Is there a XMLRPC service available from Uniserve?

I thought you had mentioned some years ago you were going to write 
a rpc service ...???

Btw, you might have a look in UniServe/clients/rconsole.r. It should 
be easier I think, to modify this script for your needs than RMC.

Doc, I have a question, and possibly a suggestion based on the answer:


is there a way to tell cheyenne  to HALT when it finds ANY config 
error?


I have been having a lot of problems that where due to the config 
not being ok and me not seeing the (shy) error message... 

currently, cheyenne starts and its in an invalid state ultimately 
doomed to failure and without a clear way to determine what's going 
on when the requests do strange stuff.

No way currently, it's a pending issue. The policy to apply is not 
that simple, I may agree on halting when the server starts but how 
to handle the case when you reload config when the server is already 
up and running? I would prefer the server to keep running with the 
previous config file rather than halting. I'd like to handle the 
config error loading case in a consistent way if possible.

sorry I jumped the gun a bit hehe... firefox showed it without new 
line... but I'm looking at the source with newlines now..

I have pretty steep requirements for the remark caching engine, but 
I'm gearing it towards long-term file caching, I was defering any 
RAM cache to a later date... funny how you pop up with such a thing 
right now :-)

I'd need a /time refinement returning what the date of the cache 
entry is for sure.  cause many cache conditions are time based in 
remark.

if so, I'd be very tempted to use it pretty soon. within a week probably.

it would be very usefull for me... the cache engine may actually 
cache the whole page if some cache keywords are at the top and bottom 
of a page

you give it a time to live and a block if its expired, the block 
get executed and cache updated

ah that's a nifty idea. :-)

I want to use anything that is out there... your service is a low-level 
construct I can surely leverage... I'll probably add a few refinements 
to it when I finish the caching engine... right now I'm dealing in 
other  lower-level remark internals.

(self modifying parse rules which adapt while parsing the file... 
a lot of fun :-)

hehe... its taken me years of practice to get at this point.  I'm 
not a "natural" parse guy.

Instead of having a complicated cheyenne/rugby hybrid ... we just 
use the rsp engine.   When the first client starts up, it uploads 
all the necessary sources for the functions it needs.  cheyenne then 
makes all these functions available to its worker processes ( perhaps 
storing the sources in its virtual disk cache ...

that lead to a enormous security problem no ?

Getting an error trying to get php running with cheyenne.


Works fine on xp pro but on mt win server 2003 box I get a dialog 
saying "apppication is configed incorrectly. Reinstall may fix..."

(I get this when I try to run php from the php icon. In xp pro I 
would get the dos box indicating that is was running) 


I know its nothing to do with cheyenne but has anyone seen this...
php is not installed

I tried a differnent version...teh "thread safe" The previos was 
"Non thread safe". Neither worked...

would it be possible to log POST data (truncated if too long) on 
cheyenne maybe .. I would like to make a parser that would warn me 
of common hacking attempts by looking at log

It's possible, but you need to add code for that in mod-static/logging 
handler. Also note that writting data on disk is a performance killer, 
so you need to implement some form of memory buffering to keep good 
server performances.

If security is a big concern, I would rather use a C-based filter 
proxy or an IDS tool like Snort (requires careful configuration to 
avoid too much false alarms).

It's more that I want to observer the http traffic for things I set-up 
.. but a lot of data is in the POST-s ... could I use your regular 
logging and just add the post string ... if it would be longer than 
X chars I would truncate it.

this is good then I can really make it a little more usefull and 
use it on all my projects .. if you need something like it tell me, 
(it's still very simple)

alias "/path/to/target" %script  -- I found this  .. can I use regex 
or something else to do 

AliasMatch ^/some-(.*) /script.rsp?a=$1

I don't have time now to investiguate much further this issue, I'll 
have a look tonight.

in mod-static/filter-output I patched this line:
req/loops < 4
with
req/loops < 1
so after intercepting an urs I can still set a 404

Will , thanks a lot, works like a charm :)

good so, means Dock did a great job, but that we know already 8-)