World: r3wp

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

yeah, but you still have to put the code behind.   the web-api mod, 
provides an interface automatically based on what is actually being 
served.  you could easily build a little WSDL to REBOL api file converter. 
 just load the XML, extract the methods, the parameters and build 
an equivalent rebol function stub.


Then all you'd have to do is implement the function body....  the 
only detail is the xml datatype which don't all map 1:1 within rebol, 
but that can usually be pretty well cornered within the code itself.

maybe even just provide a little PARSE rule which provides input 
validation representing the given schema.

anyhow... for now SOAP is a larger beast to tackle and I'm more concerned 
with REST stuff right now, but since the system will be working and 
you can easily extend it, there is nothing stopping you from building 
the SOAP interface.

(if you need it before I can tackle it)

what is the most trouble free linux to run cheyenne on?

I've never had any issues with ubuntu that I couldn't solve

except

how to start Cheyenne automatically ...when linux starts up.

maybe Someone here knows how?

For me, the most trouble free Linux to run Cheyenne is Syllable Server 
:-)

For autostarting (and shutting down) you have to hook into the init 
scripts, which are very different between Linux distributions. I 
remember having trouble with finding a straightforward way on Ubuntu, 
too

This any help? http://embraceubuntu.com/2005/09/07/adding-a-startup-script-to-be-run-at-bootup/

pwd

Oops, that was meant for my terminal

Cheyenne revision 134:

- FEAT: new config option (globals section): 'allow-method. Extends 
allowed HTTP methods.

- FEAT: -w command line option extended to allow to specify an additional 
"start" number value.

- FIX: -w 0 now starts Cheyenne with no workers at all (was spawning 
one at start until now).
- DOC: updated %changelog.txt (was lagging behind a bit).

See %changelog.txt for more info.

Linux binaries r134 should be available in an hour at: http://cheyenne-server.org/download.shtml

Cool, thanks!

I still need to add some documentation to the wiki for .r file handling 
in RSP context and to mention the new cgi-conf script (from onetom).

what does Database C drivers: MySQL 3,Oracle 8 ... mean, btw?
it doesnt work with mysql 5 and ora 10?

Those drivers are built in REBOL/Command. It depends if Mysql 5 and 
Oracle 10 servers are compatible with older drivers. I can only answer 
for Mysql, and the answer is no.

so what's the point supplying those builds, only the https support?

or why not if u can anyway?

Not everybody run on Mysql 5 and Oracle 10, so it can be useful to 
some users. Also it's all or nothing, I cannot chose which native 
feature I want to include or not.

The ODBC driver and the SSL support are worth it.

makes sense, thx for the explanation. it just looks a bit lame to 
talk about mysql3 in 2011, isn't it?

I should maybe remove that mention from the download page...I agree 
that it looks a bit odd now.

I've upgraded Cheyenne to the latest binary, r135

It recognises the fast-rebol-cgi keyword in the globals now, but 
it doesn't seem to do anything. It seems to try to execute REBOL 
code as real CGI. It tries to use the shebang line and has permission 
problems with CGI files that it didn't have before

Thanks for the report, I will test it locally later today.

having issues starting the cheyenne server from win. it doesn't find 
the system libs.


 I had a fix for the same issue in some other code I did... I'll try 
 to see if this cures the bug in cheyenne .

What do you mean by "system libs"? kernel32.dll?

it turns out it was a different problem... he was running core.  
 but the proper way of loading libs (and I've had to do it to make 
it work on 64 bit systems)

system-libs-root: rejoin [to-rebol-file get-env "systemroot" %"/system32/" 
 ]

kernel32: load/library join system-libs-root  %kernel32.dll
user32:   load/library join system-libs-root  %user32.dll
advapi32: load/library join system-libs-root  %advapi32.dll
shell32:  load/library join system-libs-root  %shell32.dll
iphlpapi: load/library join system-libs-root  %iphlpapi.dll

I was using the simple setup you are using and it woudn't work in 
all people's windows system... the above does work in all windows 
machines.