World: r3wp

Wil, thanks. Looks very promising.

Graham, it's not always possible. In this case, I have REBOL scripts 
in AltME for remote update and collaboration, that are started by 
external launchers or the command line

If someone edits a script on Windows, when it messes with the first 
line, it won't start any more on Linux

Doc, where does Cheyenne get the location "C:\Documents and Settings\All 
Users\Application Data\Cheyenne" from? Is it hard-coded or do you 
retrieve it from the registry like Windows does?

The registry key is "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell 
Folders", the value is "Common AppData".

If you take your setting from there, Cheyenne will be compatible 
with Vista, Server 2008, and weird setups without change.

I think you can also use the SHGetFolderPath API.

Yeah, that is the Windows API that retrieves the values from that 
area of the registry. You will need to determine which is easier: 
Using the built-in registry APIs or creating a routine! wrapper for 
SHGetFolderPath.

Cheyenne uses SHGetFolderPath( ) API.

Cool :)

I think that the API approach is more reliable across Windows versions 
and flavors.

Robert: you can use get the wrapper for this API function in Cheyenne/misc/win32.r.

Doc, what's the appropriate way to process http methods ... such 
as delete, put, options, get, post ... if one wishes to write an 
API based upon these?

REST for Cheyenne!

probably past his bed time now ....

He'll read later, and in the meanwhile you can read the Cheyenne 
docs, samples and source.

I've only ever used RSP with Cheyenne.

though I did build a smtp server using Uniserve once ....

Prior to today, the only thing I knew about REST was that it existed. 
 Now, ... I'm thinking that it might just be the way to go to provide 
web services for non REBOL clients.

The trick is that many HTTP clients only support GET and POST.

which is why I was hacking the http protocol recently to add the 
others

Presumably javascript supports all http verbs?

I wouldn't presume that - test first.

Or look it up.

is this the way to support all clients ?  from cellphones, to pdas 
and then full featured client browsers

well i only used get and post so i can't tell the others options

If you only use get and post, you can't do REST - it requires the 
others.

Handheld devices may be another matter. Many of them have poor JavaScript 
support, and most don't support XMLHTTP.

Those might require old school HTML get/post interfaces.

Which can also be implemented as Cheyenne proxies to your same LNS 
service.

how would one use cheyenne to load/balancing redistributing the resources

Cheyenne docs look a bit sparse ... the wiki sections are all looking 
for an author except for RSP. http://cheyenne-server.org/wiki/Main/HomePage

Docs: I put the wiki online mainly because several peoples asked 
me for one so they can contribute by documenting Cheyenne...

REST: The starting point is to authorize all HTTP methods by adding 
them in mod-static/method-support callback. Then, if Cheyenne doesn't 
choke on them (should be treated by default as a GET, but untested), 
you can write a dispatching RSP page that will basically do a : switch 
request/method [GET [...] POST [...] DELETE [...] ...]. The upcoming 
v0.9.19 release will bring a URL aliasing feature that will allow 
nicer and more RESTful URL.

so people asked for a wiki and then don't contribute?

Load balancing: if you're using RSP, you got it for free as each 
RSP is executed in its own separated process.

I think Brian was talking about using Cheyenne to do load/balancing 
for another application

as a proxy

maybe the one that asked are now too busy...anyway, the wiki was 
a good testbed for enhanced PHP support in Cheyenne.

method-support: func [req][
		if not find [HEAD GET POST PUT] req/in/method [
			req/out/code: 405
			return true
		]
		none
	]

Proxy: it can be done but requires a little more work, like building 
your own mod-something and implementing an async client protocol 
in Uniserve (unless you want to use the built-in HTTP async client 
protocol).

missing DELETE, OPTIONS, and FOO

just extend the method block list with whatever method you need

so, how would one determine if it's a REST request or just a ordinary 
other request?

the restriction on method was done mainly for security reasons (no 
appropriate default handler for other methods except these 4). PUT 
is treated by default like POST.

REST = HTTP request, so it depends on which handler will respond 
to the HTTP request. If your URL point to a .rsp => RSP handler.

Ok.

So, this is very doable then?

So your REST URLs have to point to a .rsp resource.

Well, in theory, yes :-)