AltME groups: search

As a remainder, all the Cheyenne source code, including the service.dll 
source is release under BSD license.

=> "as a reminder ... "

Re service.dll : it could be used to add NT-Service support for any 
REBOL app. But currently, there's a few hardcoded parameters in the 
C source, so it would need at least a recompilation to work for another 
app. I was thinking about packaging this into a simple library...I'll 
see if can find some time to do that. But, in all cases, it requires 
at least /Library component.

If it is solid, I could use such a dll right away.

I'm a little curious as to what service.dll does. As Dockimbel said, 
it is currently Cheyenne-specific, and it currently doesn't come 
with source (that I can find yet), but looking at the calling source 
it seems that it does not handle all of the service-related functions, 
just "ServiceLaunch". I wonder if there would be some merit to putting 
wrappers for the other service functions in that dll, or converting 
the ServiceLaunch function to REBOL and just doing calls to system 
standard dlls. Pulling the existing REBOL wrapper functions out into 
a seperate script and generalizing them would probably be a good 
idea, at the least.

service.dll does has a minimal effort to support services. It has 
only starting and stopping support. Stopping triggers a UDP packet 
sent to Cheyenne process to notify the shutdown message. That's the 
only way to communicate with a REBOL process. Windows message cannot 
pass because it requires a permanent window structure (not possible 
in service mode). Pipes coud be a solution but they don't trigger 
events in REBOL wait loop.

To be more accurate, it's possible for a service to have an opened 
window  (even if it's not visible) to receive messages, but in this 
case, I never was able to make it survive a session logoff / logon 
sequence. In Windows, there's also threads message queues, but REBOL 
doesn't seem to trigger events from that channel too. If SYSTEM port 
was able to support that way to communicate, that would be a better 
way for the DLL to transmit messages from the service manager.

My service DLL spawns a new thread to respond to SCM (Service Control 
Manager) messages. The main thread is still the one from Cheyenne, 
if Cheyenne dies, the service dies too. That's an intended feature. 
The SCM has built-in service automatic restart capabilities, you 
just need to properly configure that in service's properties.

BTW, I recall that Hamachi includes a -srvany parameter that tells 
it to ignore logoff messages and just pay attention to shutdown messages. 
That kind of thing may be doable in REBOL too, with the system port.

There are times that I wish REBOL had a facility similar to BackOrifice, 
which dynamically linked to libraries stored in exe resources without 
having to extract them. The equivalent in REBOL would be to load/library 
from a binary! value.

That would be a very handy feature. In R3, with thread and good callback 
support, the service DLL would be useless, you could do all in API 
calls from REBOL.

will there be a VID based config UI for it?

VID based config : it's a planned feature, but I need first to finish 
the web-based version. The VID version could be done quite easily 
using the same HTTP API.

doc: source code service: not like docbase. it's more for control 
of what versions a user can download, discerning between stable, 
unstable versions. also delivers a clean upgrade procedure that is 
easy for the user. one can download scripts, packages of scripts 
and on-demand encapped executables. it works all inside REBOL/Services, 
but I need a "virgin" entry, so new users can get their programs 
through a webbrowser as well.

(which I expect will be a year from now at this pace)

but the basic idea is that developers should have an easy way to 
distribute their programs and users should have an easy way to upgrade 
their rebol applications. there are some tricks involved to lock 
it down so only specific users can get specific updates for specific 
programs. it may be tied into a purchasing system as well. that's 
where the on-demand encapping comes in.

it is much more than just providing links to scripts on a webpage.

A Cheyenne front end could be very useful. Cheyenne could easily 
use REBOL/Services for login.

Apparently it's not in the main cheyenne.r file, but during a call 
to a sub system (don't know which yet) that causes this.

Doc, are you considering simple HTML templates for .rsp pages, or 
is that already possible?

Such as converting a block of values to a table:

<% print html-table read %. %>

It's not on my Todo list, I plan to make a higher level framework 
for building web applications, where I don't want to mess anymore 
with HTML or Javascript. Kind of VID dialect that compiles to HTML+CSS+JS.

umm,  okay, well maybe this is the right place for a small problem 
I've encountered with  cheyenne / uniserve -- maybe not an issue 
with the server but me being new to rebol -- btw this is on windows 
2000 and happens with both cheyenne and uniserve -- when I go to 
any cgi or rsp page a new rebol console pops up in front of the browser! 
Is there anywhere in the uniserve / cheyenne source where I can disable 
this behavior?

Softinnov.org is back online. There's some bad URL requests using 
not supported HTTP method that sometimes crash Cheyenne. I'm working 
on a fix for this and will publish it asap.

While you're here -- I noticed that Cheyenne failed to fetch a jpg 
image that had spaces in its src url -- e.g. "red rock river.jpg" 
-- and "red rock river.jpg" didn't help either ...

(uniserve didn't have a problem with this btw)

-- btw wanted to say how delighted I was to find a lightweight, scriptable, 
no-hassle-to-install, x-platform web server -- many thanks!!

I plan to make a new release this week, only bugfixes.

I had a problem with port 80 at first -- this both in uniserve and 
cheyenne -- changed the hardcoded port assignment in httpd.r to 8880 
and it worked fine

woops -- just attempted to register a new acct w/ yr bugtracker -- 
got the email confirming, went to the indicated url -- found a bug 
;-) --> > RSP Error Trapped<

Error Code : 	310
Description : 	script error !
validate-user has no refinement called update
Near : 	[if not validate-user/update request/content [err?: yes]]
Where : 	protected-exec

funny bug... I guess that's a regression from last restore after 
the server's disk crashed...

give me a few minutes to fix that...

Doc? -- just filled in a ticket but when I tried to submit I got 
"Access Denied" ... bzzzzt

After rebooting my OSX machine, Cheyenne doesn't work anymore. I 
didn't change anything. It starts and runs and launches its task 
handlers, but there is no access from a webbrowser. Does it create 
some kind of start up log so I can tell what's wrong?

I'm planning a Cheyenne bugfix release tomorrow, if you've found 
some new bugs to fix, please report them in Cheyenne's bugtracker 
or post them here. Thanks.

Go Doc Go!   Not a bug note or anything, but I'm becoming very intrigued 
by the potential of emedded Cheyenne.  Go Doc Go!  ;)

Yep; and some.  I have visions of suger plums dancing in my head. 
  REBOL Website bundles.  Transient home PC whiteboarding.   Kick 
Cheyenne and dance with a browser, have your friends attach to the 
ip and then, after the fact close up shop.   Zero-conf temporary 
web hosting, and the apps are pure REBOL scripts.   Sweetness abounds. 
 I  think up new applications just about everytime I think about 
Cheyenne now.   I was busy when you announced .9.16 so I didn't think 
deeply enough about it (I woohoo'ed, but thaty was it)  It struck 
me like lightning the other day.  I broke with tradition and dropped 
a note to Carl, I was so excited.   GO DOC GO!   :)

This is a bugfix only release, it fix many bugs, especially the one 
introduced in the previous release causing an exit from the main 
event loop. See details in %changelog.txt.

Doc - think you need to check the Cheyenne blog rss setup, when I 
subscribed and followed a link it went 404 and pointed to the following.


http://softinnov.org/article/0017.html

rather than -


http://softinnov.org/cheyenne/blog.cgi?view=0017

FYI, Rod.

but that is mostly ajax, and load is put on the flickr api.. now 
for something that really use Cheyenne rsp power, check this http://beta.arounder.com/amsterdam/city_tour/van_gogh_museum_01.html
click on the "read" tab, there is a little number in gray, that is 
page generation time, then reload the same page and check again, 
it use a uniserve/service memcache, also conside that it's on a multilanguage 
framework 8)

Btw, just as teaser, Cheyenne will soon have its own dedicated website 
with documentation and a roadmap for all planned features in future 
versions..among them, there's a new server-side framework providing 
100% separation between HTML and processing code. Petr, you gonna 
love it ;-)

will we have much of a rewrite of existing apps?

Sure, It's just a matter of configuration in %httpd.cfg file.

I would also like to add AJAX and DB abstraction layer, but I didn't 
yet decided what approach would fit the best with REBOL. It needs 
a lot of experimenting first.

clean and complete separation between HTML and REBOL code
 

So you are not mixing rebol code with html in one file? (like in 
RSP)

But your building web pages using rebol code alone? Is the server 
acting like a serverside "plug-In"?
Sorry if I sound completley novice.

hmmm... I'm building a dialect that builds HTML code, in a sense, 
weeding out the need for HTML code inside the rebol code. is that 
what "x" does?

I've tried to get it up and running (Magic!) but have never got it 
to work. Apachi always gives me a hard time. Since its CGI based 
I tried with Cheyenne but again unsuccessful.

Are you going towards a asp.net style special tags model for the 
dynamic widgets?

Brian, nothing specific, it just looked "too big" last time I've 
checked the source code which was a year ago. I should have a look 
in Devbase for the latest version of LNS.

I've been wondering what it would be like to have a rebol version 
of asp.net.  I'd like to see a solution that separates the HTML and 
the logic as discussed, but also get rid of the css, javascript, 
xml and other languagues that get in the way of a streamlined solution.

Hi guys, there's a tiny issue with Cheyenne running on 2.7.6 due 
to a bug fixed in EXTRACT. To fix it just open %HTTPd.r file and 
find the  following line :

EXTRACT (on pre 2.7.6) was always returning a block! value.

Next Cheyenne release will include this bug fix. The next release 
should be soon because I intend to make some deep internal changes 
in RSP to support different HTML processing engines (not only the 
current one with mixed HTML and REBOL code). This shouldn't affect 
the RSP API or behaviour, just the internal design. So, I plan to 
make a new release before starting these changes.

I don't know if current rebservices can use HTTP protocol as transport. 
Rebservices can run in the same process as Cheyenne, but processing 
rebservices requests may slow down Cheyenne's performances a lot. 
R3 threading will solve that kind of issue, so we'll see in a few 
monthes. ;-)

Watch out with EXTRACT: There is a bug in the 2.7.6 version with 
binary values that was fixed, but the fix never made it into 2.7.6. 
You can get the working version from DevBase r2-mezz-series #396.

The discussions that Paul and I had resulted in some R2 optimizations 
for EXTRACT, but those optimizations never made it into the 2.7.6 
release. The semantic changes that prompted your bug fix originated 
in the R3 version of EXTRACT that we wrote back in November, and 
were a result of discussions of the severe limitations and bugs of 
the old EXTRACT.

True and there's a small limitation there that I will need to solve 
in the future versions.

Interesting comments, I should maybe move the URL parsing later in 
the processing pipeline or, instead, provide a hook for modules to 
be able to rewrite the URL before it is parsed. Anyway, you can change 
the URL, path, target and ext (+ req/vhost) in any module's phases 
if needed, but a clean way to do it is preferable. The hard part 
for making a good rewriting engine is, IMO, to invent a good clear, 
clean and compact dialect to achieve that...regexp are not really 
my taste.

You're right about mod-alias, it's not completed yet. I found it 
might be redundant with a rewriting engine, so I left it unfinished 
until mod-rewrite comes.

If I have a proxy server made in Uniserve, what is the best way to 
join it with Cheyenne?

Hard to answer, but as it's propably the most important software 
component for my company, quite a lot I guess.

With PHP I often use code like:
<? if(something) { ?>
 normal HTML is here
<? } else { ?>
 something else here
<? } ?>

Don't you miss some way to do such a conditions?

And as I'm now writing RSP I found the RSP's <%%> tag much more difficult 
to write than PHP's <??>

Just as a reminder for those currently using Cheyenne/RSP, you can 
add the DEBUG keyword in your webapp config section in %httpd.cfg 
to display a menu with useful debugging info.

impressed! 8) I finally gave another try at php support in cheyenne 
and after patching fastcgi.c as suggested it now works like a charm.

If you are on os x and use macports, here is a way to patch and compile:

sudo port install php5 +mysql5 +fastcgi
sudo port uninstall php5
cd /opt/local/var/macports/distfiles/php5/
sudo tar -xjf php-5.2.6.tar.bz2
>> run patch below
tar -cjf php-5.2.6.tar.bz2 php-5.2.6
sudo port install php5 +mysql5 +fastcgi checksum.skip=yes

copy of Dockimbel's patch with path fixed for this example

;---- cut'n paste the following code in REBOL's console ----

patch-php: has [buffer pos][ target: %php-5.2.6/sapi/cgi/fastcgi.c 
if none? attempt [buffer: read target][ print "unable to find the 
file to patch!!" exit ] either parse buffer [ thru "int fcgi_accept_request(" 
to "if (req->fd >= 0) {" pos: to end ][ insert pos "^/^-^-^-^-break;^/^-^-^-^-" 
write target buffer print "patch applied." ][ print "failed to locate 
the line to patch!!" ] ]
patch-php ;---- end of code ----

I just installed drupal 6.2 in a snap on Cheyenne, I really love 
the cleaning they have done on the database structure. If only it 
was in rebol...

Pekr, forget joomla, that is bloated stuff, drupal is elegant, has 
good community and good documentation. I like the cleaning they have 
done with the database structure in latest version. It looks to me 
they have so much reduced the code a good php/rebol coder could translate 
it in a week.. ;-)

Erlang, no, I just looked at the language specs and a few examples, 
why ?

Here's a Yaws (Erlang based daemon) vs Apache benchmark.
http://www.sics.se/~joe/apachevsyaws.html

Shows Yaws handling 80,000 parallell connections.

This bench looks a little odd to me. First, how can Yaws supports 
80,000 parallel connections when running on a single server (TCP/IP 
stack limit is at 65535 AFAIK) ? Second, the load is generated by 
sending request byte per byte with a delay of 10s between each bytes 
and getting in response a file of 1 byte...This isn't a web server 
real load test, it just compares the scalability of OS threads vs 
"soft threads". You don't need a benchmark to know which one scales 
better on a mono-CPU server, it's obvious. How Erlang handles multi-core 
CPU ?

Although it is possible to take advantage of multi-core technology 
by running several applications processes in parallel, the real benefit 
would be for multi-threaded applications. The challenge then is to 
change single-threaded or sparsely threaded applications into multi-threaded 
and also to debug them.

Erlang has unique properties for taking 
advantage of multi-core technology
One of the fundamental properties 
of the Erlang language is built-in support for very light-weight 
processes, each with its own memory, and using explicit message passing 
for their communication. Because of this most applications written 
in Erlang are realized as a number of cooperating Erlang processes 
representing something in the problem domain of the application, 
for example active call sessions, connections or transactions. Typically 
this will result in many thousands of simultaneously executing processes 
in a heavily loaded application.

The parallelism already present 
in most Erlang applications makes them ideal for taking advantage 
of multi-core technology, without there being any need to modify 
them.

The only thing needed is an Erlang virtual machine (VM) which 
works in a multi-threaded way, and that is what we now are releasing 
in Erlang/OTP R11B.

Cheyenne, with its mono-thread full async engine, would scale very 
well on a similar benchmark, probably much better than Apache, but 
less than Yaws I guess. OTOH, a bench testing raw throughput, would 
show Apache performing quite better than Cheyenne (maybe 2 or 3 times 
better). It's hard for interpreted REBOL to compete with compiled 
C on raw power. I think that it would be possible to reduce this 
difference to 1.5 with deep optimization in Cheyenne (task scheduled 
for v1.1 according to my roadmap). R3 should open new perspectives 
for speed & memory optimizations (threading, clean async kernel, 
optimized ports, Rebcode, plugins...).

Erlang has a lot going for it, but it has its own set of issues as 
well. Maarten recently spent some time evaluating it quite deeply 
for me. At this point, we're sticking with REBOL.

Was? That's a new project :)

A good starting point for doc links is http://www.erlang.org/doc.html
.


The pros are that it's been around for a long time, it was built 
to solve a specific type of problem, and has been proven to work 
for large commercial systems. It also has a nice community it seems. 


Just as C# and VB.net are capable languages, you really need to know 
the .NET framework to make things sing. Erlang, by itself, is very 
capable, but the OTP (Open Telecom Platform) provides a huge amount 
of value on top of it, if you're building distributed systems. It 
also has Yaws, Ejabberd, and other things already built that you 
can leverage.


On the downside, it's a very different model that takes some getting 
used to, though Maarten got up to speed for experimentation very 
quickly. If you're used to Prolog, that will help. It's also really 
only good for back end stuff, so we would still be doing front ends 
in something else, which wasn't the dealbreaker in our case. What 
turned us away was the security model. It's designed for use in an 
intranet type (read safe) environment, where access to machines on 
the cluster is controlled by secret cookie. If your cookie is compromised, 
they have absolute power over the node, and any nodes it shares that 
cookie with.  http://www.erlang.org/doc/reference_manual/distributed.html#11.7


We decided that, since we would end up building security on top of 
everything, using something like dialects for control, we were better 
off sticking with REBOL. There are a number of things out there already 
to bulid on (LNS, Rugby, Uniserve, BEER), we can really do things 
the way we want, in a tool we know we like and are comfortable with. 
And we know its limitations, so there will be fewer surprises.

Doc, the 64K limit is the limit on the number of server ports but 
not the number of connections that can be open to a single port like 
port 80

AFAIK, every client or server connections are taking a port number 
in the 64K range. Each time a server receives a new connection it 
assigns a local port number to the client connection. That local 
port number is in the 64K range because TCP (or UDP) header storage 
space for source or destination ports are only 16bits each.

In theory, a combination of a client IP and a local port (in the 
64k range) could make a unique key allowing to handle more than 64k 
clients, but I don't think that the big 3 OS are able to exploit 
such trick in their default configuration.

There is a paper on Philip Wadler's site: http://homepages.inf.ed.ac.uk/wadler/documents/ServiceArchitectures.pdf


Check footnote 32 on page 21 (chapter 13). That's what stopped us.

doc, in erlang concurrency is supported in the programming language 
(i.e. does not use the os mechanisms). I am trying to track down 
a reference were it explained you could have 2 power 32 connections 
theoretically

Pat e wrote:
> Can anyone tell me how can Yaws have almost 80,000 concurrent

> connections, and some "home-made" erlang servers over 110K concurrent
> connections if there are only 64,000 tcp/ip ports?

A TCP/IP connection is identified on each host by a
(local port, local IP, remote port, remote IP) tuple.


Therefore, there can be more than 2^16 connections to a server (even 
if

the server is listening on a fixed port) provided that they are from 
more
than one client.


In theory it's also possible to have more than 2^16 connections between 
a

specific pair of hosts provided that they use all of the available 
port

combinations. However, TCP/IP stacks generally do not support reusing

local port numbers (when the port is not specified by the client 
software)

by default, so the practical restriction in this case may still be 
2^16.

-- 
David Hopwood

Handling 64,000+ concurrent clients is a problem I wish I had.

Yep, in real world, there's no point accepting more than 10k connection 
on a single server. You usually hit memory and cpu limits far before 
reaching that limit. Spreading the load among multiple servers is 
the way to go. That's why the Yaws vs Apache benchmark sounds so 
theorical and irrelevant to me.

hi doc, I have a c++ backg. and seen plenty fo 30k+ concurrent but 
yes for web sites its common to have a hw redirector and multiple 
servers

CGI environment is not supposed to be persistent, so there's no other 
ways than to manually add libs loading code to %CGI.r script. If 
you're encapping Cheyenne, you can add your libs to %cheyenne.r (and 
don't forget to LOAD them too). If you need a persistent environment, 
use RSP instead.

Think we might try using Cheyenne as a personal web server, providing 
functionality similar to Adobe Air, Google Gears for our product.

Here's a little video clip of a prototype in action.. 
http://kommonwealth.com/video/cheyennewidgetdemo.swf

That's all taking place in the browser, being served up from our 
server.. and accessing a copy of Cheyenne running locally. No cross-domain 
issues here :)

Basically it's the part which was showstoper for Rebol plugin - shortly 
it works in a way, that if you want to connect to some site with 
Flash, Flash first loads crossdomain.xml file from the target server 
where must be your domain allowed to access the server domain. If 
it's not allowed, the Flash do not connects at all. It's a basic 
prevention of doing Dos attacks from Flash Player.

stick them on google as a googledoc :)

can cheyenne be used to spawn a new task for a 3rd party application?

I've added a url-aliasing feature to Cheyenne, so now the wiki will 
be more search-engine friendly. The new URL for the wiki is http://cheyenne-server.org/wiki

I agree, I was planning to change the baseline since a while.

don't want to be judgemental just saying...not a big deal, but note 
that Apache uses the feather, far more neutral

Is there anything that would cause Cheyenne to crash? I've not yet 
tracked down the bug, but every time I click a specific link on one 
of my .rsp pages, it just dies and needs to be restarted. Unfortunately 
it's now gone so far that it seems not to want to serve pages anymore 
even though it's running. Under OSX, I get this log output:


Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68212 PPID 68210 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68211 PPID 68209 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68210 PPID 1 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68209 PPID 1 
rebol


Are there any file permissions, that if set wrong, would cause cheyenne 
to stop serving pages?

if you have a specific rsp that create the problem I'd be glad to 
have a look and test here

1. Variable overwrite is a possibility. 2. I don't use PHP fastcgi. 
3. If I could get Cheyenne to serve pages again, I'd be happy to 
recreate the problem. The server is (was?) running on port 80. I 
don't see what or how that could change

I use a Virtual hosted site. Does anyone else out there do the same? 
I'd like to confine my Cheyenne tests to a particular test site and 
not affect all the other sites. Yes, I suppose I could also do everything 
locally but it would be fun to have it "live and real." I'm wondering 
if anyone has some thoughts about this. I'm not a linux/apache wiz 
so I'm not sure if the httpd config can be set for a specific site 
or is it global?

What is what? Do you want to run Apache or Cheyenne? Do you have 
Apache virtual hosts, or a complete virtual server that you can install 
your own software on?

Kaj, I guess it is my ignorance. I thought Cheyenne ran under Apache. 
I have a GoDaddy virtual server that is running Apache but apparently 
I can also install my own software:
What can I install on my virtual dedicated server?

You may install anything you want to on your virtual dedicated server—as 
long as you do not violate the restrictions listed in your license 
agreement.

That said, I think it is possible to run different web servers on 
the same web site. For example, it is possible to have a leaner web 
server handle static content and have Apache handle dynamic content

Doc?  Can you post quick download links for some variations of uber 
cool blue C logo you've created.  Perhaps one with a Powered By in 
your favourite forms?

I take a look at the config file.