Re: [Proposal] "Relayed" Apache API Project

[Shachor Gal <sh...@techunix.technion.ac.il>]

  >  My proposal is to separate the discussion it 2 or 3: 

  1. What API do we want to expose to remote engines ( for example
sub_request but not pool ).

  2. What wire protocol should we use ( message format and encoding, CDR
or
  XDR or AJP or something else ?)

  2 or 3. What communication mechanism - TCP is a clear one, but we want
to
  support unix pipes or shared memory or doors.



Lets follow this proposal..

>  
>  It is not very difficult to make it modular - and probably the best way
to
>  start would be to re-use some existing code and then invent new
protocols.
>  

True, and we will probably end up with a modular approach.

>  
>  I think the API is the most difficult and important part, it's a big
>  difference between local calls and IPC ( we must expose non-trivial
>  calls, etc). 
>  
True, lets ask ourselves what is worth exposing...

IMO we must be able to provide the following information:
- Apache environment variables
- CGI environment variables
- SSL data
- Initial path translations.
- HTTP data including:
    - Headers
    - Body

We should also provide the following services/:
- Start response
    - Set status
    - Set headers
- Log data
- Reject a request (do we really need it)
- Translate path to mime and
- Translate url to path

(this is an initial list and I may have forgot something.)

Note that I am using abstract terms rather then the actual APIs. This is
because I
think that we should not do an RPC call for each api call (for example we
should
not make an RPC callback whenever someone adds header, but instead flush
all
headers when ap_send_http_header(rec) is called). This also makes it
possible to
check and see if the suggested set of APIs can be supported by Netscape
and IIS.

Costin, other then mime and uri translation, what other sub-request
services
do you think of?

>
> 2. What wire protocol should we use ( message format and encoding, CDR
or
> XDR or AJP or something else ?)
>

Gee, here we go again...

- I do not reject to CDR
- We can use the GIOP header as our message header
I think that re-implementing an ORB or just putting one inside the web
server and
Tomcat/Catalina is a good way to kill performance (I am talking from
experience here)

>
> 2 or 3. What communication mechanism - TCP is a clear one, but we want
to
> support unix pipes or shared memory or doors.
>

Unix domain sockets/Pipes/shared memory or doors are all OK, all we need
is a stream
based interface (in any case Unix domain socket/Pipes are all based on
shared memory
so using shared memory + synchronization may not yield improved
performance).

For WinNT (or W2K or whatever) we should also consider Named Pipes.
The WinNT Named Pipes are *not* similar to what happens on UNIX, but they
do provide
a very fast (shared memory based) transport layer.


  Gal Shachor

Re: [Proposal] "Relayed" Apache API Project

[brian moseley <ix...@maz.org>]

On Tue, 1 Feb 2000, Shachor Gal wrote:

> Costin, other then mime and uri translation, what other
> sub-request services do you think of?

i'd really like tomcat to be able to generate subrequests
and internal redirects, and set up custom error responses.

Re: [Proposal] "Relayed" Apache API Project

[brian moseley <ix...@maz.org>]

On Tue, 1 Feb 2000, Shachor Gal wrote:

> Costin, other then mime and uri translation, what other
> sub-request services do you think of?

i'd really like tomcat to be able to generate subrequests
and internal redirects, and set up custom error responses.