World: r3wp

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.

Our bots weren't the brightest :)

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.

something which requires natural language interpretation.

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

If you prevented those spam tickets, you wouldn't have to worry about 
space!  :)

www.rebol.net and mail.rebol.net are different machines. it's not 
the rambo spam that's filling mail :)

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

I was just reading about SCGI today: http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
Would there be an advantage to implementing this in Cheyenne?

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

having fast-cgi would be fine. But - fast-cgi does not have sense 
for Cheyenne, no? Hmm, maybe it does, when you use e.g. php ...

Cheyenne has FastCGI already, and uses it to call PHP..

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

See the roadmap at http://www.cheyenne-server.org/roadmap.shtml(at 
1.x section).

Byte-Ranges

 -- way down the roadmap list after big-sounding items :-()  I have 
 to wait. No problem.

(Hmm... isn't it pretty easy, though ?)

(I didn't say that - of course it isn't as simple as it seems on 
the surface..)

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.

Umm;   Go Doc Go!   not that you haven't heard THAT one before.  
;)

Just wanted to say I've started using Cheyenne with RSP yesterday 
to make some webapp and so far it all works awesome-ly! :)

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 !

Thanks for these interesting info. Cheyenne has been optimized for 
speed, caching in memory, at all levels is the key for performances. 
There's still some space for some speed improvements.

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

the biggest blockage in developing learning was just now when I was 
making login function and it stopped setting cookie, it took me at 
least half an hour looking at the code and then I discovered I disabled 
cookies by accident in FF webdev toolbar :)

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.

doc: I will tell you if I get any ideas while working on it .. so 
far nothing substantial.

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

Yes, background servers are customary for solving the logging problem, 
in Unix for example, and it may also make better use of multiple 
CPUs or cores

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.

gregg can you read Dtrace sample output? I have an issue where cpu 
goes 100% and no clue what rebol is doing so, on os x 10.5 intel 
I can sample that process but have no clue on reading it

My experience with DTrace is mainly studying the design. How useful 
the output is depends on the probes, which REBOL won't have to help 
us at the app level. What probes are you using?

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.

linode or slicehost? Marteen is for slicehost, Ken Collins is for 
linode, I like linode, any last counter advice? thx!

I liked linode but haven't tried slicehost yet

will you be using it for server or something less hungry , like crawler, 
bot.. etc? because for that there are even cheaper vps-s

I'll use it for cheyenne, web serving, thx for your advice, if nobody 
comes against linode , I'll go for it 8)

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.

In addition, as space allows you can have multiple different profiles. 
So you could run different distros from the same VPS, although not 
simultaneously.

yes, the different profiles is really cool feature , especially at 
developement experiment time

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