World: r3wp

so, now app-init.r works for whatever reason. at least I can observe 
that changes to app-init.r only take into effect after restarting 
Cheyenne.

 => Webapp are persistent application in memory. RSP pages will be 
 reloaded on modification but %app-init.r can't without "restarting" 
 the whole application. As there's no clean/reliable way to completly 
 "unload" a Rebol app from a Rebol session, it requires to restart 
 the whole processes (all the worker background processes that may 
 have run your webapp). This can be achieved either by restarting 
 the whole server, or better, by using the "Restart Workers" feature 
 (documented in the changelog file). For unix: kill -USR1 <pid> (where 
 <pid> is Cheyenne main process id).

Btw, the usual way to not have to "restart workers" on each app-init 
or other memory cached code is to run cheyenne with -w 0 option (use 
only 1 worker process and kill it after each request) and some verbose 
output for debugging :

 ./cheyenne -vv -w 0 &

on each app-init or other memory cached code [modification]...

Use the provided TestApp webapp sample to get a real working example. 
You can build your app by copying testapp code, then customizing 
it if you don't feel yet comfortable with webapps framework.

Graham: I'll release a new SVN version in a few hours after fixing 
known bugs/issues and rewritten netutils and file attachement stuff 
to get rid of Rebol non-conforming legacy code.

No rush ...

I need it to be fully operationnal for tomorrow, we're starting UAT 
for a customer app relying on it. ;-)

Correcting myself about my claim regarding CRLF not sent by REBOL 
built-in protocols : REBOL does send CRLF even if 'newline if used 
as line terminator. A conversion is applied and it becomes CRLF once 
inserted in the port. This automatic conversion (LF=>CRLF) is OS 
independent and is triggered by /lines refinement used on OPEN native 
in root-protocol/open-proto. AFAICT, this behaviour is not documented 
explicitely anywhere. I can just find a few mentions about such conversion 
here : http://www.rebol.com/docs/core23/rebolcore-12.html, but it 
looks like it's related to FTP scheme only (while in fact being the 
default for all schemes relying on OPEN-PROTO).

yess.  I've had to battle this in the past when its not desired.

I wonder if the /lines is a recent refinement or if I just never 
noticed it.

IIRC, it's here, at least, since v2.0.

here=>there

darn, a single little thing goes unnoticed and this ends up causing 
so much grief!!  :-)

bad side of working with black boxes...

<sigh!>  I wish I'd known about /lines hehe... I had to go through 
countless hours trying to fix the headers and when doing multipart... 
god... it was horrible to fix.  ;-)

I ended working in binary mode exclusive, this way I could at least 
get precise lenghts... which didn't change halfway through the process 
 ;-)

exclusively.

most rfcs of that time user crlf

Well, as soon as it is updated ... I'll be ready to test the MTA.

SVN r21 :


FEAT: log verbosity handling refactored, now more consistent across 
modules

FIX: email.r lib doesn't interfere anymore with other Rebol built-in 
schemes
FIX: bug in multipart/form-data decoding in RSP.r
FIX: email.rsp demo script now handles attached file correctly

wow that was quick!

and the windows 7 issue?

Couldn't access my Win7 box, so could test it. I'll be able to do 
that only tomorrow.

If you're still having issues with the MTA, please active maximum 
log level : -vvvvv and send me the output on private channel or by 
email.

so could (not) test it...

Did encapping solved your DNS lock up issue on Win7?

Yes... but now the new encapped version won't run.

Hmm... will do another svn up

try source version...

Testing from fresh checkout : error popping up at start

Fixed in SVN r22, please update.

win-get-dns: does [ return 208.67.222.222 ]

So, you have to hardcod the DNS server IP address?

to run as source ...

ending progress: [error [compkarori-:-gmail-:-com] {421 4.4.5 Server busy, 
try again later. 8si31346080pzk.8^M }]

sending ..

let me try my own dns

nope... not working.  just says pending.

oh ... ok.  got something back!  :(

someone doesn't like me ... ...sending progress: [error [compkarori-:-gmail-:-com] 
{421-4.7.0 [203.97.98.9] Our system has detected an unusual amount 
of unsolicited^M }]

421 code might be used for greylisting...

Ok, sent to myself .. and worked.

After reading http://en.wikipedia.org/wiki/Greylisting, I'm think 
that I really need to support that feature.

ie. my own domain .. so it looks like gmail now has greylisting

BTW, in Chrome the attachfield does not show up.

Doesn't like me using 209.85.222.8 ( read dns://gmail-smtp-in.l.google.com 
)

just get pending ...

I see the name of attached file once pick up using Chrome 3.0/Vista.

oh .. so you need to select a file first to see the field?

Interesting .. didn't know Chrome was that smart.