World: r3wp

Under web-app (at least that's where I used it).

sorry, webapp

Check both.

I assumed it only put file data there and still captured the non 
file data into request/content

 => it requires to send data using "multipart/form-data" encoding.

BrianH answered correctly, 'post-mem-limit allows you to set the 
maximum size of incoming data stored in memory. If that threshold 
is reached, all request content data is flushed on disk to avoid 
memory starvation attacks.

what's the default limit ??

100'000 bytes IIRC

ok.

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.

though consumes more network resources

Seems I continue to have the need for basic authentication to allow 
3rd party resources access pages.

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)

Dunno .. but at present I am putting files into public to allow 3rd 
party apps to access them ... and using very long filenames to obscure 
them

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).

Is this something we can use ? http://babelserver.org/rebol/memcached/

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?

if you want so, just uncomment or change this line in UniServe/services/cache.r 
:
if client/remote-ip <> 127.0.0.1 [close-client]

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

Getting this is in the latest Cheyenne when encapped

7-Oct-2009/12:12:03+13:00 : make object! [
    code: 500
    type: 'access
    id: 'cannot-open
    arg1: "/C/Rebol/UniServe/protocols/DNS.r"
    arg2: none
    arg3: none
    near: [do any [get-cache file file]]
    where: 'do-cache
]

Why should it be looking for dns.r when it should be inside the cache?

Because you need to "refresh" the .encap.fs cache file before encapping 
by running Cheyenne in source mode at least once. This procedure 
has to be done each time the SET-CACHE spec block in %cheyenne.r 
is changed.

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.

Could you just use UniServe with async HTTP protocol? (I can put 
it online, it's not part of Cheyenne package)

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
     ....

Could try the async http protocol but it's currently written for 
https

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?

I'm currently trying to find out how to make it repeatable. It seems 
to only happen somestime (or I don't understand the situation at 
the moment). I add some debug output and will keep an eye on it.