World: r3wp

Also, I might have changed the shebang lines in CGI demo scripts 
to Windows format for local testing without reverting them to UNIX 
format once done.

I think that I'll setup some automated nightly builds, but probably 
only for Linux target as a start. I could later add Windows support 
(I have a Windows box running 24/7), but MacOS will be missing.

if you have all the setup and scripts, I have a mac machine running 
24/7... it could easily grab the lates svn and dump the build where 
you want  :-)

No time tonight to setup the automated builds, will do that tomorrow 
after finishing 8/16-bit support in Red/System.

thx for not disappearing in the depths of ur cave without a word 
;)

my jsondb works with angular now thru cheyenne, btw. no delete though, 
but not a big issue yet.

Ditto. Doc seems to work harder on Cheyenne while taking on Red. 
Maybe we should come up with a third major project for him ;-)

If you can provide me a solution to avoid sleeping, why not. ;-)

I've been working on one, but I still need to debug it. The current 
method causes crankiness

my take on sleep  :  The most useful way to waste time    ;-)

I guess you're forced to that conclusion if you have kids :-)

hehe

I don't even consider it wasted, because I know my brain programs 
on while asleep. At dawn, it will often have worked out yesterday's 
problem. The question is whether the code input of Doc's extra project 
can fit in his waking time

yeah, I know... I have 4 batch cores (which is why I often work as 
quickly on 4 projects as some do on one  :-)

but when the problems are complex, the night sleep doesn't fill up 
the whole time slot.   i.e. the solution is resolved and there is 
still a lot of batch time left.

btw folks, a funded, cheyenne-related project I'm working on has 
been green lit for public release.  I'll be doing a full announcement 
tomorrow on what it is, and possibly even a prototype code release. 
 :-D

give us a hint

a small bone will do

web api

FYI, I'm working on setting up automated Linux builds for Cheyenne.

Automated builds are now up and running (Linux only): http://cheyenne-server.org/download.shtml

I will push some changes tonight to see if it works as expected.

r u generating that download.shtml dynamically?

very nice download pages.  probably one of the most conscice page 
of this kind I've ever been to  :-)

i found the version numbers pretty confusing though and the binaries 
are not sharply separated from the source packages

newcomers have no freaking idea what is pro and what is cmd..

but i don't have any explicit idea how to make it better, so i didn't 
want to complain yet ;D

he actually does give the difference between /pro and /command on 
the page.

but do i need a keyfile to run it? is it legal to run it? if there 
is a version which knows such extra features but still miniscule, 
what's the reason having to separate versions?

I guess there is one title which might be added... 
Nightly builds:


just before "Sources tarballs of latest revision are also available"

compiled versions do not require a key, that is what paying the SDK 
is for.  there is no need to talk about license keys within the binary 
packages... 


there could be another page which lists all the various source license 
and REBOL interpreter requirements though, 
with just a link on this page.  something like:


<a href="rebol-vs-cheyenne-licensing.shtml" >notes about required 
REBOL license and interpreter version requirements for use of source 
versions </a>

(should remove the first "required" in that sentence ;-)

keys are not required to run sdk/command encapped builds

keys are only required to do the encapping

Thanks for your suggestions, I'll try to improve this page, especially 
for newcomers that don't know about REBOL.

ok, so I promised a little announcement about work I have been doing 
in/with/for cheyenne...

I have built a web service module (mod) for cheyenne.
  -----------------------
  features/highlights
  -----------------------

   * extremely fine tuned to cause the least cpu hit on the server process 
   since ALL processing is done in worker processes.

   * it uses an arbitrary number of rebol script files which you assign 
   to any host in the config file. (even the default)

   * once assigned, these files are compiled dynamically (as one app) 
   by the mod and are exposed via http by the server.

   * only the functions you *chose* are *ever* visible on the web, allowing 
   you to include support libs, data and function right in your server-side 
   api.

   * no direct execution of code occurs, *ever* from the client to the 
   server, all input is marshaled, and parameters are typed to your 
   function specs.

   * allows ANY type of web api to be delivered, from REST to SOAP like 
   interfaces.

   * output is programmable, so that you can output AS  json, xml, html, 
   txt, etc.

   * interface is also programmable, so that you can provide GET params, 
   POST forms, POST (XML, JSON, REBOL native data)

   * Automatic API documentation via source scanning and function help 
   strings .  there will also be some form of comments which will be 
   used by documentation.

   * No suport for sessions. this is part of your application layer, 
   which should use https and session keys in the submitted data, if 
   you require it.

   * it takes litterally 5 minutes to convert your internal rebol code 
   into web services which obey internet standards.

   * System is auto-reconfiguring... i.e.  you don't need to close cheyenne 
   to update the service, just restart the workers.

so, when will this be available?


*very soon*  I am building my first test release for my client tonight.


most of the research and prototyping is done, I already did some 
client demos for the people who are funding this project and I'm 
now in the "delivery" phase.


The most complicated parts of the system are already working (i.e. 
handler processes, dynamic compilation, automatic api interface building, 
per-host api/config, request/response chain of command, multi-format 
output, and more.)

a lot of details are still "up in the air" as far as implementation 
goes, so if you really have a need for this, PLEASE STAND UP and 
raise your voice.  tell me what you need, how you want it to work, 
etc.

so far I plan to deliver the first release with: 

  support 4 interfaces for calling : GET url, POST XML, POST Form data, 
  POST JSON.

  support 4 output formats : XML, HTML, JSON, TXT (which is in fact 
  rebol native data)


obviously this will be an ongoing project and anyone who is interested 
in helping out is welcomed to do so.  :-)

Sounds cool Max. We have some Cheyenne work going on, so this is 
definitely of interest.

Interesting ... I just Cheyenne for pure http and don't serve other 
web services yet

I think this mod can open up new opportunities for cheyenne (well, 
its already opening up one more client of mine to cheyenne  :-). 
 
especially when you'll see how brain-dead it is to setup.

brain dead is not a requirement I hope!

hehe

maybe I just make the config file in brainfuck language, just to 
make it look like its a sophisticated thing... I mean, when its too 
easy, it can be taken for granted  ;-)

I recently implemented a soap api to interface with an online accounting 
package

But I'd like to take it all inhouse as it were.  So, I could use 
this to reimplement the server side SOAP services?

yep.

because the system actually self-identifies its available interface, 
we could even generate the SOAP xml schemas automatically, as in, 
totally dynamically.

So, all I have to do is provide the WSDL ?

and it creates the soap services for me :)

actually, you just provide the code and the WSDL would be built for 
you :-)

the otherway suits me better .. that way I can use someone else's 
WSDL