World: r3wp

So the answer is indeed that this is nothing more than a normal request 
yielding a response, where the response happens to be JSON or maybe 
even full JavaScript. This depends entirely on your own server and 
client programs, not on the intermediating web server

The code in my Try REBOL site supports this, although it isn't even 
used that way

If you view this page https://fd.cloud-ehr.net/drugreactions.rsp?rxcuilist=855348541713 541713 849339 108911


Does your browser complain that it doesn't understand what to do 
with the rsp page?

I have this which I thought should be enough

response/buffer: to-json ResObj
response/set-header 'Content-type "application/json"

cheyenne for R3 exist ?

cheyenne for R3 exist ?

I think not. R3 has different port model. First the Uniserve engine 
would have to be ported. Then I am not sure, if Cheyenne uses DLL 
interface or not, but DLL interface is not present in R3 too, we've 
got Extension interface instead. And IIRC, one of main reasons why 
Doc did not port Cheyenne to R3 was - lack of multitasking/threading. 
So - unless RT brings tasking on-board, no Cheyenne for R3.

Graham: Chrome shows the JSON output while FF offers to download 
it. It's better to use a READ and a JSON decoder from the console 
to display JSON strings or a plugin like Firebug rather that rely 
on the browser.

Cheyenne on R3: R3 lacks /Shell and /Library components that Cheyenne 
requires, and R3 is still far from being stable (both in design and 
implementation). Extension is also far from being a /Library drop-in 
replacement, I don't want to have to write and maintain per-platform 
C code, that defeats the purpose of using a (supposedly) cross-platform 
tool and it's, IMHO, a big regression from R2. Moreover, once concurrency 
support at low-level will be ready, a big part of Cheyenne would 
need a re-design and rewrite, so I prefer to wait for that for a 
real added value of a R3 port.

Doc, I've noticed also that Firefox seems to prioritize the extension 
over the content-type header.

My Firefox 3.5 wants to save the file. Isn't that a normal reaction 
for a bare json file?

Browsers saving a received content with a application/* mime type 
looks logical to me (unless requested from a JS XHR object).

What I mean is that FF appears to value the RSP extension higher 
than the content-type header.

in some instances

I don't think that can be concluded from this case alone

I have another page which sends application/pdf and it downloads 
the rsp page instead

Or was it application/xfdf ...

If it downloads the RSP, that would be a problem in the Cheyenne 
configuration, because it is always supposed to execute an RSP

Are you sure it's Cheyenne what is giving you the rsp page?

What else?

it downloads the rsp page instead
 Do you mean that you get the RSP source or RSP output?

RSP output

What's the problem, then?

Graham: you should try by adding the following header to your RSP 
script outputting a PDF file in order to display it in the browser 
:
response/header 'Content-disposition  {inline;filename="doc.pdf"}

This is what I am sending

HTTP/1.1 200 OK
Server: Cheyenne/0.9.20
Date: Thu, 02 Dec 2010 15:33:25 GMT
Content-Length: 475
Content-Type: application/vnd.adobe.xfdf
Connection: Keep-Alive
Content-Encoding: deflate
Set-Cookie: RSPSID=XESYTVZSEFSXPQHCTITGRDQG; path=/md; HttpOnly
Cache-Control: private, max-age=0
Expires: -1


Firefox opens up the PDF referenced in the xfdf file that is downloaded.

Chrome just downloads and saves the content.  So maybe it's just 
Chrome's PDF "plugin" that doesn't understand what to do ...

Seems like a Chrome mime type mapping issue, see : http://www.google.com/support/forum/p/Chrome/thread?tid=43bec1a85f6c7c9c&hl=en

Doc - I would like to ask about your argument of R3 missing DLL port 
- just shortly - what is Cheyenne using DLL interface for? And second 
- DLLs are generally not cross platform too, no?

/shell is available, just less powerfull. /wait was added at least. 
/output is not there, but in such a case /wait is sufficient - you 
can redirect to file, and read it after the return from the call/wait 
.... it is just a note, I don't want to lobby for R3 port, that would 
be - preliminary :-) ... at least unless concurrency model is available, 
it would be worthless ...

What is Cheyenne using DLL interface for?
 

- UNIX: CGI support, running as user instead of root, management 
of external servers (like PHP)

- Windows: CGI support, external servers (PHP), Desktop detection 
(for hiding working files), NT Services support, mutiple instances 
support, systray menu

DLLs are generally not cross platform too, no?

DLL are not, but the mappings to the DLL can be written easily in 
REBOL code, no need to go down to C. I see that as a big advantage 
in simplicity and maintainability.

/shell is available, just less powerfull.
Cheyenne requires /info, /output, /input and /error.


/output is not there, but in such a case /wait is sufficient - you 
can redirect to file, and read it after the return from the call/wait

If you want to have the slowest CGI support in the world, that's 
a good way for sure!

That sucks then ... RT's attitude is - do it yourself, as it is 12 
pages of C code, and we don't care about having R3 doing at least 
the same stuff as was possible with R2. I described the syndrome 
here:


http://rebol.net/wiki/What_makes_a_good_beta#Wrong_attitude_towards_finishind_R3.3F

(talking about the /shell in above message)

As for /DLL vs Extensions - I don't think that for middle experienced 
developer Extensions are dificult to handle. I looked into LUA, and 
it is just similar. Of course there still might be the need/wish 
for R2 DLL interface, and hence I raised the bounty. IIRC we collected 
450-650 USD. Max tried to pick-it-up, but he then started to complicate 
things into some C code wrapper automatition, and did not deliver 
....


Some ideas were collected here - http://rebol.net/wiki/DLL_Interface


I (and I think others too) would like improved DLL interface to exist, 
being based upon Extensions, and such extension being native part 
of R3 ...

I posted above stuff not to start advocacy here, but to remind ourselves, 
what was last conclusion ...

Pekr, what is the problem? One can make 'DLL interface' Extension 
(and I bet such extesion will be done by someone soon)..also CALL 
is part of the hostkit so it can be improved and in worst case you 
can make own CALL command! using the extension approach.

RT's attitude is - do it yourself, as it is 12 pages of C code, and 
we don't care about having R3 doing at least the same stuff as was 
possible with R2. I described the syndrome here


From what Carl told me, producing that code took an enormous amount 
of resources of several of his best coders at the time it was made, 
because there is a lot of trickery involved. It took a lot of research 
and he is therefore probably not inclined to do it again that way 
for R3. Maybe a smarter method will come up, but would you rather 
have him dive into that for 3 months or finish R3?

Cyphre: "the problem" is, that even 650 USD was not enough for any 
skilled developer to pick-up. Or maybe just - to prioritise it ....

even 650 USD was not enough
 That just means:

-people who might do it consider it not enough for the time they 
would spent on
or

-noone really needs it so urgent to pay it as contractor work instead 
of bounty

Henrik - RT should take care of defining a product. No matter who 
does it in the end - RT themselves, contracted developer, sponsored 
developer, whatever. I expect DESIGN of the product being fully in 
hands of Carl - from tasking, to shell interfacing. Here's the guru 
here (that is not to say that other devs can't design the solution), 
but really - Carl should be an architect ...

Cyphre - you still use the same attitude I mentioned in the article, 
and that is wrong with me, sorry. The feature is either being put 
on the list, or it is dismissed from the list of available features. 
Carl stating something is complex is not argument for me.

The other problem is, that no possible developer said - guys, raise 
at least 1500 USD, and I might consider it ...

I don't need it myself now. I might learn to use Extensions, and 
simple /shell might be sufficient for me. But we are in a Cheyenne 
channel - no tasking, no DLL, no /Shell - no Cheyenne for R3. No 
Cheyenne for R3 =  no Cheyenne at all in the long run imo ... easy 
as that :-)

What list you mean? IMO the dll interface won't be part of R3 core 
as it is platform specific code so logically it can become:
1.embedded extension in HostKit
2.external extension


There nothing which will prevent anyone to make external extension 
and then show it to Carl to adopt it into official host-kit release 
as embedded solution. So I'm still missing your point here.

Also from what I understand. Carl has lot of work on finalizing the 
design of R3core lib now so ti can go BETA. So IMO it is too early 
to make some 'fixed' configuration of the official hostkit. I believe 
He'll try to define the official hostkit set after the r3core goes 
beta.

I expect DESIGN of the product being fully in hands of Carl
 - Why?


Part of the point to the host kit application structure is to allow 
Carl to focus on the core stuff and leave the periferal stuff to 
other people. This is partly done to be able to get other perspectives, 
and partly to relieve Carl of work that he doesn't need to do. Don't 
we want the work to go faster?

That is nothing which prevents ...

 ... there is nothing preventing anyone coming with networking protocols. 
 Yet r3 oficially supports only half-baked http :-) What I say is 
 - there is certain feature-list ... and product comparison table. 
 If RT decides to claim on their website - DLL interface for R2 is 
 not available, use more flexible Extension interface instead - fair 
 enough. But it is RT who owns the product, it is RT who defines its 
 features, and it is RT who needs to accept consequences - Doc stated, 
 why he will not port Cheyenne to R3, that is all ... and it is his 
 free will to state that ....

...but even if Calr defines official hostkit without DLL interface 
feature I don't see any hurdle that we could have external extension 
maintained by thrid party.

The other thing is that Carl thinks the solution is so obvious that 
he has not told us what to do, because he expects it to be happening 
now on a per-platform basis as part of the hostkit, just as Cyphre 
describes. So while we're arguing here, and no-one is doing anything, 
in a few months time, he'll be surprised that nothing has happened. 
We should probably get him to make a blog post on it for "directions".

Core stuff like tasking, the security model, evaluation, these are 
all best done by Carl. CALL doesn't need to be - that is why its 
implementation is in the host portion.

BrianH: "and leave the periferal stuff to other people" - I know, 
what I am trying to point out though is, that - it does not work 
(as can be seen with networking). The GUI would not be here, if it 
would not be sponsored by Robert. So I just asked, how much is eventually 
needed, for someone taking the DLL bounty? I surely am not able to 
write it myself, nor are other ppl, but we might be able to collect 
a sponsorhip fee :-)

We advise Carl on stuff all the time as well, even on the core design. 
He is always looking for new ideas.