World: r3wp

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

RC is ultimately limited by the Active Record pattern though.

Which maps table -> port, record -> object.

Charles, sounds like your pick if you want an object interface to 
your database :-)

I WIll look into it.  Now the question I am trying to come to grips 
with the whole abstraction of tables vs hiting services to query 
the database directly and return the data. Anyone care to weigh in?

do you mean n-tier?

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.

I'm trying to serve JPGs through an RSP Page.  The following is the 
entire contents of the RSP Page:

<% 
	do %init.r

 results: SQL rejoin [{SELECT data FROM images WHERE id="#^{} select 
 request/content 'id {^}"}]
	unless empty? results [
		img: first first results
		response/reset
		response/set-header 'Content-Type "image/jpg"
		prin img
		response/end
	]
	print "FAIL!!!!"
%>


This seems to almost work. But I have to load the result twice in 
REBOL to actually get the image.


view layout [image load load http://localhost/image.rsp?id=375A5EDB9102ECB08B3A185186650D3C]


Displays the image.  The value returned from the Database is Binary! 
so it should be the same as read/binary as shown in the example of 
how to do this in the Cheyenne docs, shouldn't it?

Any ideas?

I simplified the RSP Page to:

<% 
	response/set-header 'Content-Type "image/png"
	prin read/binary %temp.png
	response/end
%>


and now the browser says, "The image 'http://localhost/png.rsp'cannot 
be displayed, because it contains errors" but the previous example 
of LOADing the url twice displays the image correctly in REBOL.  
There must be another content header I need to set...  Researching...

WOOT!   Solved.


In the Response/Reset  example in the docs you use PRIN to output 
the image data, but in the Response/Buffer example you use RESPONSE/BUFFER 
to send the image data.  

<% 
	response/set-header 'Content-Type "image/png"
	response/buffer: read/binary %temp.png
	response/end
%>

Works.

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

Thanks!

For some reason Cheyenne is eating up GBs of RAM.  Once it crashed 
saying something about not enough memory (it was using 900+ MB)  
I restarted the server and it works fine except that I have seen 
it use up to 1.5GBs of RAM.  Windows Task Manager (on Vista) baseline 
RAM usage is 500MB, however, after I killed the process using 1.5GB 
Task Manager claims that only 300MB of RAM is used but it still says 
that 1.5GB of RAM is cached and says I have 7MB RAM free.  I have 
2GB physical RAM.   The problem may also be Ashley's SQLlite driver 
as I am using that to manage some images.

I've never seen Cheyenne do this.

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.

Hrm...  The script wasn't loading the image where I thought it was. 
The data was actually Binary!  not Image!  so I'll have to do some 
more digging...

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.

I'm using the encapped version...

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?

Yes

Can you elaborate or point me to something somewhere that demonstrates 
how you did it?  I'm being lazy and I don't want to figure it out 
on my own. ;-)

Ask Terry ... he has he says.

I also installed the yahoo javascript libraries ... and they're using 
Ajax ... and it's all being served by cheyenne

Ajax is just javascript making an asyn http call

I know what AJAX is.  ;-)  I've used it many times, I've just never 
set up the server side before.  I am planning on using the json.r 
script from the Library...  I'll just play with it and see what I 
come up with...

Strange...  


I added some working JSON...  Somehow the .rsp file handling the 
JSON request is using functions that aren't including in the rsp 
file.  Is it supposed to do that?

Do you have an example?

I have tag.r that has 

tag: context [add: does [something]]


I DO tag.r on most of my RSP pages but not on json.rsp yet I'm using 
TAG/ADD in json.rsp without problems.

Sounds like it is being set globally?

tag is being set globally but I didn't expect includes to be persistent 
across different pages.

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.

Btw, if your %tag.r script is required in most of your RSP scripts, 
just DO it once in 'on-session-start (in %app-init.r).

btw, love the new website  :-)

feature request: add on-global-page-start and on-global-page-end, 
same as on-page-start and on-page-end but executed for all rsp pages, 
not only for webapps

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

Will: I'll consider that for the next release.

Has anyone written Atom or RSS output code in RSP? I am going to 
need to do so right away and every possible speedup helps.

I remember an RSS output snippet. It's probably in the REBOL library

By Chris, if I'm not mistaken

http://www.rebol.org/view-script.r?script=emit-rss.r

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

Thank you both :)

Graham, did you ever get to switch to slicehost or linode?

I have slicehost. Highly recommended.

Fast, super simple. Not the cheapest, but you definetely get what 
you pay for (which is very good, in their case). They also have good 
docs and wikis - that's an example for many services!

What's the minimum you need to run Cheyenne?  the encapped binary 
and what else?

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

Thanks