World: r3wp

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.

hmm, so I turned it into advocacy anyway :-) Wrong channel again, 
sorry for that ...

Switching to advocacy.

Doc stated, why he will not port Cheyenne to R3, that is all ... 
and it is his free will to state that 

I said I won't port it now, because doing that now would be like 
shooting myself in the foot several times. I never said that I'll 
never port it in the future. When R3 will reach R2's level of features 
and stability, I might port it (irony not intended).

We look forward to that, seriously. But I at least understand that 
it is not appropriate to port it now. I hope to get advice from you 
about HTTP support in R3, when such advice is needed - that would 
be great :)

HTTP protocol is one of the simpliest Internet protocol to support, 
nothing that a skilled developer like you can't handle. :-) Anyway, 
I would be pleased to answer questions, as my free time permits.

Cool, thanks. And I expect that the Q&A will likely be asynchronous 
:)

Probably :)

Doc, yes, that was nothing against you. It was more about Pekr's 
response to your decission to not port to R3 at the moment (which 
is understandable).

Doc, I wonder, It should be not that hard to use R3 for the cgi part 
only, right ?

I guess that not harder than using Perl as CGI or PHP as FastCGI 
under Cheyenne.

I that material up-to-date ?
http://www.rebol.net/r3blogs/0182.html

*Is that...

It's working here under windows with R3A110 (when I change the first 
line of course).

I confirm it's working ok with a110 under Win7.

That's standard CGI, but what would be needed to give R3 a Fast CGI 
interface?

A FastCGI server protocol implementation in R3.

Are requests serialised to a FastCGI server, or is the server supposed 
to multi-task them?

Both are supported by the protocol, afaik, depending on the particular 
server settings.

Serialised operation would be easier, until R3 gets proper tasking

FastCGI requests are serialized by Cheyenne, but without tasking, 
R3 will still process one at a time, so any blocking call or long 
processing will block the whole server.

The R3 server, right, not Cheyenne?

In theory FastCGI can support app pools, for multiprocessing rather 
than multithreading (iirc from the docs).

You might have to roll your own app pools though, like Cheyenne does 
for RSP requests.

App pools running in separate processes?

Seperate R3 interpreter instances.

Yes. I'm not very interested in those, because if I would make an 
app server, it would be to cache my app. I probably wouldn't want 
multiple processes of the app server, because the caching would multiply

That model is already supported in Cheyenne. The drawback is that 
it has to be wrtten in R2

The main plus for FastCGI of REBOL is to cut down on startup overhead. 
You can do things with persistent state too.

Yes, plus the startup overhead of the app

Yup. The downside to app pools is that you have to coordinate access 
to the data amongst multiple interpreter instances (less cache, more 
disk access), but that's not as big a problem for mostly-read apps.

Yeah, I'm mostly concerned about optimising the read case

Cheyenne has some experimental support for FastCGI multiple server 
instances (multiprocessing) but this has never been really tested. 
The balancing is very simple, distributing requests using a simple 
round-robin method. Pool managment is minimalistic, starting all 
the instances and killing them on Cheyenne's quitting, no restarting 
or failover handling.

Interesting. So unlike UniServe, there's a fixed number of instances, 
and requests to one instance are serialised? That would be quite 
workable

UniServe worker processes don't support multiplexed requests (multiplexing 
is the right word used in FastCGI specs IIRC). The FastCGI multiplexing 
mode requires a form of multitasking support to be able to handle 
all the incoming requests in a multiplexed way. Without that, you'll 
end up with just multiprocessing, which is what UniServe+Taskmaster 
are doing for CGI and RSP scripts.