AltME groups: search

Kaj can you describe the benefit. I have seen a few sites that are 
for ORM and others against.

Abstracting data access is useful in many cases, though. For one 
thing, you could switch between a light-weight, native REBOL implementation 
and a heavier implementation using some other technology such as 
a relational or object-relational database

That's rather similar to mine, but there's a lot it doesn't do yet

it depends alot on your database schema  if you have a very straight 
forward simple schema  ORM will save you from the ravages of sql 
should you need such saving

if you dont  if you have natural keys or need unions or othe ..."advanced" 
sql  (as if there were such a thing) you will likely need to hand 
tweak the mappings anyway

N-Tier I get. Presnetation layer, App Logic, Database Layer. This 
ORM is another layer between the app logic and database and was wondering 
if you lose flexibility and performance. Is the real gain in crud 
style applications because I don't think I would want another layer 
in a BI/Reporting application.

You're right, that's an error in the example code, PRIN cannot work 
here because it will output the binary! in its molded form (with 
#{...}) and not only the raw data. Setting directly the buffer is 
the right way to send binary data (and RESET is not required in that 
case).


Online documentation fixed (RESET example changed to output a text 
content instead of binary).

I think I know what the problem is but I haven't had a chance to 
test it.   The SQLlite driver does an automated LOAD of datasets 
pulled from the DB.  REBOL has known memory leak(s) when handling 
lots of images.  I'm storing the binary value of images in the DB. 
 Thus when I pull the images out of the DB then the driver is LOADing 
them.  When I get a chance tonight I'll test this theory.

I saw such issue in Cheyenne a few times with an older REBOL version 
(2.5.xx) and it was caused by a REBOL GC bug. Never saw such behaviour 
since then.

Heh...  A more effecient design goes a long way.  I've minimized 
requests to the server and dropped the memory usage by about 75%


Speaking of minimized requests...  Has anyone done any AJAX/JSON 
stuff with Cheyenne?

Having your TAG word already defined is a side-effect of persistent 
RSP processes. You should *NEVER* rely on it, because your script 
can be executed within a different process where the word may not 
have been defined.

Maxim: thanks, it still needs a lot of work to be completed : integration 
of a CureCode instance for bug tracking, writing lot of documentations,...

http://www.ross-gill.com/page/Atom+in+a+Hurry

A config file, but if you don't provide one, Cheyenne will create 
a default one in the same folder.

This is interesting.   I'm launching cheyenne on startup each time 
my app starts.  But to see if it is already running, I check by opening 
a port.
p: open/direct tcp://127.0.0.1:8002 close p


but this causes Cheyenne ( latest encapped version ) to shut down!

I tested this with the above and a rebol console to reproduce it.

I have to go for a bit...

Oops .. changed this group to non web public ...shouldn't have posted 
this is a web public group

keep it non public, there is a wiki on cheyenneserver.org for open 
web

I am about to use Cheyenne for a project that I have just found out 
will be more public than anticipated.,

Do the Cheyenne processes disappear when your test fails? If not, 
did you try to access a web page to see if it's still responding?

ie. if I add a print between the open and close, the bug does not 
appear

Btw, did you checked for a %crash.log file near cheyenne.exe?

REBOL/View 2.7.6.3.1 14-Mar-2008
Copyright 2000-2008 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
>> do %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
    ]
]
>>

Doc, do you have a time planned for the public release of 0.9.19?

BrianH: I should have released it a month ago, but some issues with 
RSP showed up and I like to fix them before releasing officially 
the new version.

Basically, some errors are not reported or (not catched?) during 
RSP execution. I want to clean up the RSP logging code to output 
all errors to a log file.

Well, it seems to show that something changed between 2.6.2 and 2.7.6. 
I'm writing a short test server to see if it can be reproduced with 
a short block of code.

Ok, try this : paste the following code in a fresh console (2.7.6) 
and try to reproduce the error :

s: open/binary/direct/no-wait tcp://:8003
append system/ports/wait-list s
s/async-modes: 'accept
s/awake: func [server-port /local err new][
	either error? err: try [
		new: first server-port 
	][
		err: disarm err
		if err/code <> 517 [?? err]
		false
	][
		insert tail system/ports/wait-list new
		new/async-modes: [read]
		new/awake: func [port][
			print "event received"
			probe copy port
			false
		]
		set-modes new [no-delay: on]
		false
	]
]
set-modes s [no-delay: on]
wait [ ]

Does Cheyenne use the EXTRACT function? A bug with EXTRACT with binaries 
slipped into 2.7.6. DevBase has a fix.

BrianH: yes, that's related to EXTRACT but not with binaries, it's 
a side effect of EXTRACT with hash! values.

Ok, so we can now fill a nice RAMBO ticket, with an example code 
:-)

BrianH: do you have a list of patches to apply to R2.7.6 ?

BrianH: about EXTRACT, there's no bug in 2.7.6 I'm aware of, it causes 
a regression on Cheyenne only because the old EXTRACT was wrongly 
returning a block! value when taking a hash! value as input.

I will be maintaining a patch script for 2.7.6, though it is not 
yet online. All of the patches are in DevBase for now.

I'll fill a new ticket right now.

It was discussed many times. I would use javascript to hide (enter) 
the form. It so easy. Just use document.write("<input name='submit' 
value='submit' type='submit'>"); where the input is as pure html. 
Better as external javascript. so the spambot parser does not see 
it without js evaluation (which are most such a spambots)

We were getting tormented by spam at http://guitarz.org/pappgmembers/index.cgi
.  At one point I needed an immediate bandaid, so temporarily added 
a several-line cgi that just told the user to type "pappg" as the 
password, and then checked that they entered it correctly.  We've 
never had another problem since :)  Makes me think that a catchpa 
would handle a lot of grief.

You need a variety of techniques to stop all the spambots (and the 
human-assisted spambots).

Another technique is to have a hidden (by CSS) field, that humans 
don't see. If it comes back with a (changed) value, then most probably 
a bot is at work.

Sunanda, cute trick (as long as on mobile devices the CSS is not 
thrown away , which happens more and more now a days).

I suggested in the past a REBOL based question.

Graham: except for scanning for actual legit tickets, it takes me 
a couple seconds to delete those (a few keypresses after logging 
in to rebol.net), so it's not much of an issue. i have to log in 
to rebol.net daily anyway in order to log in to mail.rebol.net (only 
accessible from there) and check the free space (only ~1GB left on 
the disk). so we'd have to solve both problems at once for me to 
not have to worry about those machines. :)

Reichart -- part of the hidden text needs to be a label that says 
something like "please leave this blank" Then nothing can go wrong 
.... :-)

Oops -- Sorry, DocKimbel. We're off-topic here.

There is already a separate (and less public) group for this topic.....If 
we have more to say, let's continue in:
    Bad Bots

I have a very easy trick that works for preventing spam in forms 
but it needs aiax, no captcha, nothing to enter, ping me if interested

It's basically a simplified, non-multiplexed alternative to FastCGI. 
It seems to me that it may have less overhead.

Excuse me if I'm wrong, but "Accept-Ranges: bytes" is not implemented. 
Can this be done ?

I've just tried to resume a file from Henrik's server, and noticed 
that it has "Accept-Ranges: none". I know this means the web server 
is advertising "you can't resume!" My download client can use this 
information to avoid trying to resume, but it would be even better 
if the server allowed me to resume too :-)

It's not difficult, but requires deep changes in UniServe layer, 
so it takes some times to make the required changes without making 
regressions. Anyway, it's more a matter of priority, and dependencies, 
I need the full unit tests suite ready to start making such changes. 
From 1.0, I need completly stable Cheyenne releases without any regression.

I always thought that because cheyenne is pure rebol it will be quite 
slow but http_load got me 250 req/sec on a RSP page which is unusually 
good. I rememeber when I was playing with Lua a while ago (which 
is one of few the fastest dynamic languages) and Kepler(it's default 
webapp thing at the time) and I tested lua based webserver it was 
quite slow, same is known for webrick from ruby etc.. and also my 
php with all the needed includes were well below 50 r/s. So awesome 
job Dockimbel !

The debug mode is also very nice, catching before redirecting also 
helps a lot

If you have propositions for improving the debug mode, I'll be glad 
to hear them. 


I'm currently working on a new Cheyenne release with a big cleanup 
of all debug and error logging done by background RSP processes. 
It will basically generate only 2 log files : error.log and debug.log. 
You'll be able to send content to debug.log file using some functions 
like : 

- debug/print data

- ?? word

Btw, I've tried to use file locking method to be able to sync writes 
to the same file from several processes. None of the file locking 
code found on rebol.org works reliably enough. At best, all processes 
can write their content to the file, but the order is messed up (each 
line starts with a timestamp), so not usable in my case. I didn't 
want to try using OS native file locking API, I'm afraid that a frozen 
process could permanently lock the file and block all the other processes, 
so it's too risky (at least using only REBOL, I could have some escape 
strategy to avoid that).

So, the solution I choose was to add a log service in Cheyenne that 
would serialize all log messages passed through TCP connections and 
write them to log file from the main process. It's kind of pulling 
out the big guns for a very simple problem, but that's the most reliable 
solution I could found. I would be interested to know if anyone has 
a better option.

About how you solved it, it might seem like big guns but it seems 
very good solution for looging to me, in fact I was thinking of  
something similar and saw it on some places - that all procedures 
that aren't involved in producing a html response get offloaded to 
other processes that can take their own timepace

Same idea here Doc. Apps can do individual logging, which can then 
be merged for analysis. But if you need everything to go to a single 
log file, you need a controller for them to go through. I'm also 
still very big on the DTrace model.

I'm having trouble getting Cheyenne running as a service with windows 
server 2003. I get this message when I try to start from the services 
list:
	Could not start Cheyenne Web Server service on local Computer.

 Error 1053: This service did not respond to the start or control 
 request in a timly fashion.

are there any noticable differences in features between the two? 
I will need a new vps too soon

I have used both Slicehost and Linode. Both provide excellent realiability; 
I did not experience any downtime with either provider. Linode provides 
somewhat more memory, storage and transfer allowance for the same 
price. I ran a benchmark against both and got about 15% better performance 
from Linode.

A big advantage for Linode is the amount of control it gives you. 
With Slicehost you have a single disk volume and your slice is either 
running or not. Linode allows you to have multiple volumes. These 
can be mounted simultaneously, which can be nice if you want to prevent 
/var/log from filling the disk.

There are a variety of other nice features. You can have multiple 
users with different levels of control over your VPS. Another nice 
thing is that performance graphs are available over the web on the 
Linode Manager screen.

Another thing to be aware of is that Slicehost by default gives you 
a 64 bit distro. That caused me some problems I didn't want to deal 
with.

I was just talking to some client of mine and he proudly told me 
that they moved all stuff to 64 bit... and I scratched my head a 
little thinkihn about potential problems

Never tested the service mode on WS2003.  I have a WS2003 disk image 
somewhere, I'll see if I can reproduce the error.

wow, I imagined smaller dialect but this is quite impressive. I won't 
use it for this project as I have most made it already, but I will 
look at it deeper for next. I also made a forms dialect also, which 
is not so different than yours at first sight at least.

It would require a change in the RSP DO-SQL function to cope with 
several result sets.

Although I am using Cheyenne in the project itself, it has also been 
useful as a development and diagnostic tool lately :)

I'm working on it today, I'll release a beta version in a couple 
of hours. Lot of fixes and improvements in this release.

New Cheyenne 0.9.19 beta version available for testing at : http://cheyenne-server.org/tmp/cheyenne-r0919.zip


Tested only on Windows  (my Linux image network has currently some 
issues).

ChangeLog (diff-ed from last test version) :


 o RSP: an HTTP redirection in 'on-page-start won't evaluate the page 
 script anymore.
	

 o CGI: mezz function READ-CGI now patched to be compatible with Cheyenne. 
 That's
	  the right way of reading POST data in REBOL CGI scripts.
	  
	o RSP: fixed a bug in session/add when setting a block! value.
	

 o Task-handler: fixed a network error on first packet read (high 
 load + fast hardware).
	

 o Task-handler: TCP keepalive mode activated (test workaround half-closed 
 connections).
	
	o Task-master: 
			o 'no-delay mode removed and replaced by 'keep-alive mode

   o now forks a new process as soon as one dies (not waiting for a 
   new request)

   o fix a long standing bug in queued job module name mismatching (can 
   happen under extreme load)
			o minor code cleanup
	

 o Uniserve: 'no-delay TCP network mode now switched off for all connections. 
 Fixes a

   stability issue on Vista and probably on UNIX with very high load.


 o RSP: fix a bug in 'decode-multipart when there's no file received.
	

 o UniServe: new logger service. Now all info or error logs, and debug 
 messages from

   CGI/RSP scripts are written in %trace.log. Additionnaly, you can 
   now log messages
	  using :
	  
	  		- debug/print msg 	; msg [string!]
	  		- debug/probe value 	; any mold-able value
	  		- ?? word		; works like REBOL's '?? function
	  		- ? msg		; alias for debug/print
	  

 o RSP: in debug mode, page generation time and SQL queries stats 
 now added at bottom
	  of pages.
	  
	o RSP: error in events from %app-init.r now logged.
	

 o RSP: fix a rare RSP freezing issue when an error occurs in %RSP.r 
 (for example, by
	  a user script that breaks RSP sandbox).
	  

 o RSP: sanboxing now protects from Exit/Return/Break calls made outside 
 of a
	  function context.
	  
	o RSP: %misc/rsp-init.r file removed.
	

 o RSP/CGI: New config keyword added in global sections : 'worker-libs. 
 It lists the

   librairies to load when a worker process is started. An optional 
   'on-quit section can

   be added to call cleanup code when the process quits. Examples :
	  
	  		worker-libs [
				%libs/mysql-protocols.r
				...
			]
		or	
			worker-libs [
				%libs/mysql-protocols.r
				...
				on-quit [
					%/libs/free-resources.r
				]
			]
	

 o Task-master: now you can reset all worker processes without stopping 
 Cheyenne. This

   is usefull when you need to force non-RSP/CGI files reload (helper 
   scripts, 3rd party
	  librairies,...). 
	  
	  	Usage:
	
			Windows : tray icon -> Reset Workers
		

   UNIX : kill -s USR1 <pid>	(<pid> is Cheyenne's main process ID)
	 
	 

  o Added a -w command line option to set the worker processes number. 
	 
	   	Usage:
	   
	  		$ cheyenne -w <n>		(n [integer!] : CGI/RSP process number)
	   

    Use -w 0 to help debug CGI/RSP code by resetting worker processes 
    after each request.
	   (it's like calling "Reset workers" after each request).

Great Doc! I am really becoming a fan of cheyenne + rebol for webapps.. 
I have 2 half working in the garage already :)

(and I used a lot of stuff and been developing webapps for >4 years 
for $$)

Cheyenne new test release delayed until tomorrow. Almost a dozen 
of fixes and useful improvements were added, mostly by Will (many 
thanks to him). So a little more time is required to run non-regression 
tests.

New Cheyenne test release 0.9.19 available. Please report any bug 
or regresson here.

Changelog (diff from previous one) :


  o RSP: fixed a security issue allowing access to /webapp/private/ 
  sub-folders content.
	 

  o RSP/CGI: fix for HTTP 'Date header not being returned in some cases.(Will)
	 

  o RSP Sessions: fixed an issue with init flag when saving sessions 
  on disk.(Will)
	 
	 o RSP: now you can declare folders as valid login URL.(Will)
	 
	 	Ex: auth "/admin/login/"
	 	

  o RSP: a new session word 'from has been added. It's set to the referring 
  URL on login.

    After login, you can now redirect to the referring page (in case 
    of session timeouts
	   for example).(Will)
	   

  o RSP: a webapp can now be called without the ending slash.(Will)
	 

  o RSP: the root "/" webapp can now be declared (needs testing).(Will)
	 	 

  o RSP: new 'SID-domain config keyword added allowing to share sessions 
  between
	   sub-domains.(Will)
	 

  o RSP: now session ID can be passed as URL or POST data in addition 
  to cookie.(Will)
	 

  o New 'charset config keyword added. It allows to define specific 
  charset sent through
	   HTTP headers for 'text/htlm resources.(Will)
	   

  o RSP: Added a new function no-log in Response object. Use it to 
  avoid writing
	   log info to disk for the current request.(Will)
	   
	   		Ex: response/no-log


  o New 'mod-expire module for HTTPd. Allow configuring 'Expires HTTP 
  header. 
	   See %Cheyenne/mods/mod-expire.r for more info.(Will)

Robert, write a few helper functions and use http://www.ross-gill.com/techniques/rsp/

that way you have overhead of launching/closing a process for every 
request

My code is scattered everywhere... it's a Darwinistic tactic

this one is a little different and a bit more expensive on resources, 
if a request doesn't exist (no file match, no folder match) proxy 
reverse to cheyenne:
	DirectoryIndex default.html index.html
	RewriteEngine on
	RewriteCond /Volumes/data/web%{REQUEST_FILENAME} !-f
	RewriteCond /Volumes/data/web%{REQUEST_FILENAME} !-d
	RewriteRule ^(.*)$ http://cheyenne.com$1 [P]

New Cheyenne v0.9.19 test release available at http://cheyenne-server.org/tmp/cheyenne-r0919.zip.
This should be the last one before making 0.9.19 the new official 
version. 

ChangeLog (diff from previous one) :


    o RSP: fix in request/query-string allowing processing parameters 
    values passed through 'validate filter.
	   

  o RSP: output of RSP scripts is now compressed (using deflate) if 
  the client supports it.
	   

  o Default static files memory cache now set to 4Mb accepting files 
  up to 64Kb.
	   

  o Mod-static: fixed a bug in Last-Modified date forming when seconds 
  = 0.

Proxy : I run all my Cheyenne servers directly on web. Adding a reverse 
proxy frontend like nginx might be usefull for heavy loaded sites 
(millions hits/day) or when you need load banlancing and fault tolerance.

The compression overhead is small compared to the time gained on 
the network transfert. Here's a study from intel on that question 
: http://software.intel.com/en-us/articles/http-compression-for-web-applications/

I have some more questions:


1. Is it possible to use virtual hosting? I have a bunch of doamins. 
Lighttpd has a super-simpel and easy way to support virtual doamins.

2. I think that things like PHP etc. is supported as well, right?

Why is there a patch necessary?

Btw, the patch just consists in adding a " break; " at the right 
position in source code to avoid the other web server specific code 
on opening connection.

Sounds like a quirk that took some time to find and fix...

2.  SQLite: Is there a RSP compatible SQLite driver or is this not 
required? Meaning, I can just use the normal SQLite driver?

I want to write a shopping-cart module without any GUI stuff etc. 
Just a plain shopping cart where you can add, change, remove products 
and provide a lot of special parameters like handling-fees, etc.


Displaying the content of a specific shoppig-cart should work by 
calling a RSP page, that selects the correct shopping-cart through 
session ID and just generates a simple table etc. at the right place 
in a styled web-page.

1. When first accessed, a RSP web application will send you a session 
ID by cookie. You can send it back by cookie or included in GET or 
POST data. If you want your session ID passed inside the HTML page 
in all URLs, you have to add it in your RSP source using some code 
like : rejoin ["RSPSID=" session/id].

2. This one http://www.rebol.org/view-script.r?script=sqlite3-protocol.r
should work with RSP's DO-SQL, but untested. You still have the option 
to bypass RSP's DB layer to use any driver you like as you would 
in a normal script. Just remember that your code will be executed 
in several processes, so you can't rely on global words, nor assume 
that opening the connection just once will be enough...


Btw, doesn't SQLite have issues with write accesses from multiple 
processes? I've read that each process has to synchronize with others 
for write operations because SQLite don't provide such layer. Is 
this still true with recent SQLite version?  (Maybe I've just misunderstood, 
I have no experience using SQLite).

For storing shopping carts, do you really need a full database engine, 
REBOL blocks serialized should be enough, no?

1. "You can send it back by cookie or included in GET or POST data." 
Well, my understanding is that the YOU here refers to the delivered 
page. So, the page needs to be prepared a priori to delivering with 
either the session-id etc.

But if I do this, I won't need a cookie at all.


So, I first need to check if cookies work? Is there a simple test 
function in RSP like: COOKIES-AVAILABLE?

3. Blocks: That's the way I want to go. Using the session ID to store 
shopping-carts. And than a clean-out run after several days or so.


The problem with the session-ID not being a cookie is, that the session 
is lost if the user closes the browser and later returns. Right?

1. Good point. You need to use the session/active? to test if a session 
has been automatically created, if not, that means no cookie support 
(require to serve a RSP page first, then check on the next call to 
a RSP page, an HTTP redirection might help you do so). Then, you 
can use session/start to manually start the session and send back 
the SID.

3. Session ID are lost when the browser window is closed. If you're 
on a LAN with Windows clients, you can try getting their Windows 
login ID.

1. Just to be sure I undestand:

First I call a simple RSP page which implicitly will create a session 
of possible.


If on the next call to an RSP page session/active? is FALSE, I create 
one manually. Take the SID and use either the URL or POST option 
to transport SID back and forth?

No doc at all for config options now (anyone willing to document 
that on Cheyenne's wiki?). Ask here for info, I, Will or other experienced 
Cheyenne user can anwser your questions. 


PERSIST will allow RSP sessions to survive to a Cheyenne reboot (by 
saving them temporary on disk).

Give me a login and hack it away.

3. Ok. So, if the browser window is closed, the session cookie will 
be deleted? Or will the session survive a window close if the client 
accepts cookies?

The cookie setter can specify a deletion date, in which case the 
cookie will be removed on that date. If the cookie setter does not 
specify a date, the cookie is removed once the user quits his or 
her browser.

So either lost or survive until a given date.

just wanted to drop by and say that I published alpha of my first 
mini cheyenne webapp and it is the most responsive app I ever made 
.. it is noted also when not on local comp and someone of 2 peps 
that tried it already wondered how come it loads so fast ...  this 
is minimal app so it looks more reasonable but I know a slightly 
bigger app that I am making behaves just as fast for now..  have 
to run.. will read this cookie discussion other time

Cheyenne doesn't have built-in SSL support (Carl never enabled server-side 
SSL for ssl:// scheme). The "lighter" way to support that is to use 
a specific wrapper like stunnel. Lighttpd in reverse-proxy is ok 
too, but maybe overkill.