You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU> on 2000/02/06 05:03:35 UTC
Re: [Proposal] "Relayed" Apache API Project
>I know almost nothing about Corba so I can't really say anything here.
>But if we remove all the Corba-ish stuff from the orb and use IIOP like
>we use AJP today, I don't think it's a huge issue.
Corba is nothing without the compiled IDL interfaces and object ids.
Using IIOP to transmit a fixed subset will simply add overhead to
whatever it is that you are sending -- eventually it will encounter
an ORB that wants to negotiate or broker the interface, and your simple
implementation will just puke and die. (Of course, the same happens
to any ORB implementation that meets up with an ORB from another
vendor who hasn't cross-tested for compatibility, but that is a much
longer diatribe than I care to get into at the moment).
I am working on a tokenized, self-descriptive, bi-directional messaging
protocol that will have the capability to replace HTTP. However, it will
still be optimized for streaming transfer of data, and will simply be
"efficient" for small control messages. It is also caught amongst
too many other requests for my time, so I wouldn't suggest waiting for
me to finish.
If what you want is to add an extension to the existing Apache hook
mechanism such that the hook invokes an RPC interface, then you should
just use an existing RPC protocol with a well-defined marshalling.
However, I can tell you with absolute certainty that it will be the
wrong architecture for a high-end server implementation, so eventually
it will be replaced with an architecture that operates directly on
the data stream.
Anyway, hopefully we'll have time to brainstorm some of this stuff
at ApacheCon next month.
....Roy
Re: [Proposal] "Relayed" Apache API Project
Posted by Stefano Mazzocchi <st...@apache.org>.
"Roy T. Fielding" wrote:
>
> >I know almost nothing about Corba so I can't really say anything here.
> >But if we remove all the Corba-ish stuff from the orb and use IIOP like
> >we use AJP today, I don't think it's a huge issue.
>
> Corba is nothing without the compiled IDL interfaces and object ids.
> Using IIOP to transmit a fixed subset will simply add overhead to
> whatever it is that you are sending -- eventually it will encounter
> an ORB that wants to negotiate or broker the interface, and your simple
> implementation will just puke and die. (Of course, the same happens
> to any ORB implementation that meets up with an ORB from another
> vendor who hasn't cross-tested for compatibility, but that is a much
> longer diatribe than I care to get into at the moment).
>
> I am working on a tokenized, self-descriptive, bi-directional messaging
> protocol that will have the capability to replace HTTP. However, it will
> still be optimized for streaming transfer of data, and will simply be
> "efficient" for small control messages. It is also caught amongst
> too many other requests for my time, so I wouldn't suggest waiting for
> me to finish.
>
> If what you want is to add an extension to the existing Apache hook
> mechanism such that the hook invokes an RPC interface, then you should
> just use an existing RPC protocol with a well-defined marshalling.
> However, I can tell you with absolute certainty that it will be the
> wrong architecture for a high-end server implementation, so eventually
> it will be replaced with an architecture that operates directly on
> the data stream.
>
> Anyway, hopefully we'll have time to brainstorm some of this stuff
> at ApacheCon next month.
Thanks for this, Roy, really appreciated... and yes, I would love to
have a wide discussion and brainstorm about this at ApacheCon... yeah,
it makes perfect sense, I hope all the interested people will make it
there.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: [Proposal] "Relayed" Apache API Project
Posted by Stefano Mazzocchi <st...@apache.org>.
"Roy T. Fielding" wrote:
>
> >I know almost nothing about Corba so I can't really say anything here.
> >But if we remove all the Corba-ish stuff from the orb and use IIOP like
> >we use AJP today, I don't think it's a huge issue.
>
> Corba is nothing without the compiled IDL interfaces and object ids.
> Using IIOP to transmit a fixed subset will simply add overhead to
> whatever it is that you are sending -- eventually it will encounter
> an ORB that wants to negotiate or broker the interface, and your simple
> implementation will just puke and die. (Of course, the same happens
> to any ORB implementation that meets up with an ORB from another
> vendor who hasn't cross-tested for compatibility, but that is a much
> longer diatribe than I care to get into at the moment).
>
> I am working on a tokenized, self-descriptive, bi-directional messaging
> protocol that will have the capability to replace HTTP. However, it will
> still be optimized for streaming transfer of data, and will simply be
> "efficient" for small control messages. It is also caught amongst
> too many other requests for my time, so I wouldn't suggest waiting for
> me to finish.
>
> If what you want is to add an extension to the existing Apache hook
> mechanism such that the hook invokes an RPC interface, then you should
> just use an existing RPC protocol with a well-defined marshalling.
> However, I can tell you with absolute certainty that it will be the
> wrong architecture for a high-end server implementation, so eventually
> it will be replaced with an architecture that operates directly on
> the data stream.
>
> Anyway, hopefully we'll have time to brainstorm some of this stuff
> at ApacheCon next month.
Thanks for this, Roy, really appreciated... and yes, I would love to
have a wide discussion and brainstorm about this at ApacheCon... yeah,
it makes perfect sense, I hope all the interested people will make it
there.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: [Proposal] "Relayed" Apache API Project
Posted by Stefano Mazzocchi <st...@apache.org>.
"Roy T. Fielding" wrote:
>
> >I know almost nothing about Corba so I can't really say anything here.
> >But if we remove all the Corba-ish stuff from the orb and use IIOP like
> >we use AJP today, I don't think it's a huge issue.
>
> Corba is nothing without the compiled IDL interfaces and object ids.
> Using IIOP to transmit a fixed subset will simply add overhead to
> whatever it is that you are sending -- eventually it will encounter
> an ORB that wants to negotiate or broker the interface, and your simple
> implementation will just puke and die. (Of course, the same happens
> to any ORB implementation that meets up with an ORB from another
> vendor who hasn't cross-tested for compatibility, but that is a much
> longer diatribe than I care to get into at the moment).
>
> I am working on a tokenized, self-descriptive, bi-directional messaging
> protocol that will have the capability to replace HTTP. However, it will
> still be optimized for streaming transfer of data, and will simply be
> "efficient" for small control messages. It is also caught amongst
> too many other requests for my time, so I wouldn't suggest waiting for
> me to finish.
>
> If what you want is to add an extension to the existing Apache hook
> mechanism such that the hook invokes an RPC interface, then you should
> just use an existing RPC protocol with a well-defined marshalling.
> However, I can tell you with absolute certainty that it will be the
> wrong architecture for a high-end server implementation, so eventually
> it will be replaced with an architecture that operates directly on
> the data stream.
>
> Anyway, hopefully we'll have time to brainstorm some of this stuff
> at ApacheCon next month.
Thanks for this, Roy, really appreciated... and yes, I would love to
have a wide discussion and brainstorm about this at ApacheCon... yeah,
it makes perfect sense, I hope all the interested people will make it
there.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: [Proposal] "Relayed" Apache API Project
Posted by Stefano Mazzocchi <st...@apache.org>.
"Roy T. Fielding" wrote:
>
> >I know almost nothing about Corba so I can't really say anything here.
> >But if we remove all the Corba-ish stuff from the orb and use IIOP like
> >we use AJP today, I don't think it's a huge issue.
>
> Corba is nothing without the compiled IDL interfaces and object ids.
> Using IIOP to transmit a fixed subset will simply add overhead to
> whatever it is that you are sending -- eventually it will encounter
> an ORB that wants to negotiate or broker the interface, and your simple
> implementation will just puke and die. (Of course, the same happens
> to any ORB implementation that meets up with an ORB from another
> vendor who hasn't cross-tested for compatibility, but that is a much
> longer diatribe than I care to get into at the moment).
>
> I am working on a tokenized, self-descriptive, bi-directional messaging
> protocol that will have the capability to replace HTTP. However, it will
> still be optimized for streaming transfer of data, and will simply be
> "efficient" for small control messages. It is also caught amongst
> too many other requests for my time, so I wouldn't suggest waiting for
> me to finish.
>
> If what you want is to add an extension to the existing Apache hook
> mechanism such that the hook invokes an RPC interface, then you should
> just use an existing RPC protocol with a well-defined marshalling.
> However, I can tell you with absolute certainty that it will be the
> wrong architecture for a high-end server implementation, so eventually
> it will be replaced with an architecture that operates directly on
> the data stream.
>
> Anyway, hopefully we'll have time to brainstorm some of this stuff
> at ApacheCon next month.
Thanks for this, Roy, really appreciated... and yes, I would love to
have a wide discussion and brainstorm about this at ApacheCon... yeah,
it makes perfect sense, I hope all the interested people will make it
there.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: HTTP + XML + SCP = HTTP/ng
Posted by Dean Gaudet <de...@arctic.org>.
On Fri, 11 Feb 2000, Martin Pool wrote:
> JServ talked about using the W3C's MUX protocol to achieve a similar
> thing in the httpd-jvm connection. But honestly, why bother?
>
> Poluting the higher-level protocol (http) with performance workarounds
> for the lower-level protocol (tcp) seems pretty ugly. Good
> implementations of persistent connections seems more useful.
i consider SCP/MUX to be another transport layer... and in the context of
doing RPC over HTTP it's really beneficial in that it gives two packet
request/response. in many cases you get the ACK piggybacking as well
which cuts packet costs roughly in half. i don't really see this as a
fault of TCP -- TCP does its thing well, plopping SCP over it lets two
servers communicate efficiently at scale.
gotta remember this is at scale with lots of parallel streams going on.
Dean
Re: HTTP + XML + SCP = HTTP/ng
Posted by Yves Lafon <yl...@w3.org>.
On Fri, 11 Feb 2000, Martin Pool wrote:
> Certainly when I was active in JServ I think there was a feeling in
> the back of our minds that ``we shouldn't do our own http handling
> because we don't want to compete with the Apache httpd'', although of
> course there were other reasons. Most of those reasons have now gone
> away; Java is more or less stable and fast enough to write the whole
> web server in pure Java.
As of jdk1.1.6, it was possible to have the same level of performance
between a server written in Java and Apache (on Solaris), with just more
memory used ;)
> > about the only extension to HTTP which i think we might want to consider
> > is Simon Spero's SCP -- session control protocol. (you can find a version
> > of it named TMP used without credit in rfc2371). SCP allows you to
> > optimise front-end/back-end communications by multiplexing multiple
> > streams into one tcp session... big performance boost from this.
>
> JServ talked about using the W3C's MUX protocol to achieve a similar
> thing in the httpd-jvm connection. But honestly, why bother?
>
> Poluting the higher-level protocol (http) with performance workarounds
> for the lower-level protocol (tcp) seems pretty ugly. Good
> implementations of persistent connections seems more useful.
Well, if it is just between some machine you have control on, it is better
to fix the multiplexed connection at the tcp leve, if not, then you have
to use application level fixes, it is easier to ask people to upgrade
their software rather than their low level tcp stacks.
/\ - Yves Lafon - World Wide Web Consortium -
/\ / \ Architecture Domain - Jigsaw Activity Leader
/ \ \/\
/ \ / \ http://www.w3.org/People/Lafon - ylafon@w3.org
Re: HTTP + XML + SCP = HTTP/ng
Posted by Martin Pool <mb...@linuxcare.com.au>.
On Thu, Feb 10, 2000 at 04:03:23PM -0800, Dean Gaudet wrote:
> On Mon, 7 Feb 2000, Martin Pool wrote:
> > Given the state of Java and HTTP today I wonder whether it would be
> > better to build a toolkit of Java classes for building HTTP servers,
> > rather than using AJP to plug into Apache.
>
> that's what i was advocating.
Certainly when I was active in JServ I think there was a feeling in
the back of our minds that ``we shouldn't do our own http handling
because we don't want to compete with the Apache httpd'', although of
course there were other reasons. Most of those reasons have now gone
away; Java is more or less stable and fast enough to write the whole
web server in pure Java.
If we see Apache as a family of products then that concern goes away;
we can offer a configuration of JServ that talks to Apache and another
that runs standalone. Depending on other factors -- what fraction of
the site is servlets, whether they need SSL, and so on -- people can
choose one or the other.
> > Where's Apache going to go in the future? Is it going to be a single
> > big do-everything program, or a cluster of complementary projects?
>
> i hope not, but unfortunately there's a little bit of momentum... i've
> made a couple attempts to suggest ways we could split it up. but i don't
> have the energy to evangelise the topic.
From context I guess you mean you hope it won't be monolithic. In
that case I'm with you.
> so one of the points i brought up earlier in the thread hasn't been
> addressed: what problems are people trying to solve?
That's the question I'd really like to hear answered about CORBA
integration.
> aren't the php and java back-ends just content handlers today? they don't
> even touch other API phases right?
As far as I know that is true, for both of them.
> - they require more code, which clobbers L1 cache efficiency (which i'm
> willing to bet will eliminate any perceived benefit you're hoping for by
> making things binary)
The other important point is that it makes them very difficult to
audit and secure. There's a document somewhere that describes the
results of sending random data to commercial CORBA ORBs; almost all of
them fall over immediately.
> about the only extension to HTTP which i think we might want to consider
> is Simon Spero's SCP -- session control protocol. (you can find a version
> of it named TMP used without credit in rfc2371). SCP allows you to
> optimise front-end/back-end communications by multiplexing multiple
> streams into one tcp session... big performance boost from this.
JServ talked about using the W3C's MUX protocol to achieve a similar
thing in the httpd-jvm connection. But honestly, why bother?
Poluting the higher-level protocol (http) with performance workarounds
for the lower-level protocol (tcp) seems pretty ugly. Good
implementations of persistent connections seems more useful.
--
Martin Pool, Technical Support Engineer, Linuxcare, Inc.
+61 2 6262 8990
mbp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
Re: HTTP + XML + SCP = HTTP/ng
Posted by Dean Gaudet <de...@arctic.org>.
On Fri, 11 Feb 2000, Jeffrey W. Baker wrote:
> Dean Gaudet wrote:
> > - full HTTP/1.1 proxy cache
> > - HTTP/1.1 server capable of serving static files
> > - uses async i/o at least for serving static files (which includes
> > files in the proxy cache)
> > - capable of dividing the urlspace amongst different pools of
> > backend servers
> > - capable of load balancing amongst several backends within a pool
> > - handles persistant/pipelined connections with clients and with
> > backends
> > - SSL
>
> If #3 above includes buffering, then I'm with you. If not, I would add
> buffering. It is very important for the front end to decouple the back
> end from the client's pipe, so as to allow the two layers to scale
> independently. I realize that one can just as easily tweak the kernel's
> socket buffer size, but I believe there are smarter ways to go about
> that.
yes i knew i forgot something :)
Dean
Re: HTTP + XML + SCP = HTTP/ng
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
Dean Gaudet wrote:
>
> On Mon, 7 Feb 2000, Martin Pool wrote:
>
> > Given the state of Java and HTTP today I wonder whether it would be
> > better to build a toolkit of Java classes for building HTTP servers,
> > rather than using AJP to plug into Apache.
>
> that's what i was advocating.
>
> > Where's Apache going to go in the future? Is it going to be a single
> > big do-everything program, or a cluster of complementary projects?
>
> i hope not, but unfortunately there's a little bit of momentum... i've
> made a couple attempts to suggest ways we could split it up. but i don't
> have the energy to evangelise the topic.
>
> so one of the points i brought up earlier in the thread hasn't been
> addressed: what problems are people trying to solve?
>
> the web applications of which i'm aware are essentially composed of:
>
> - static content
> - dynamic content which is cacheable (i.e. almost static)
> - dynamic content which is uncacheable
>
> the best url design includes all these components under the same hostname.
> so either all the services end up on one box, or some sort of front-end is
> required.
>
> both apache and squid perform as front-ends today.
>
> if we had a front-end server with the following feature set:
>
> - full HTTP/1.1 proxy cache
> - HTTP/1.1 server capable of serving static files
> - uses async i/o at least for serving static files (which includes
> files in the proxy cache)
> - capable of dividing the urlspace amongst different pools of
> backend servers
> - capable of load balancing amongst several backends within a pool
> - handles persistant/pipelined connections with clients and with
> backends
> - SSL
If #3 above includes buffering, then I'm with you. If not, I would add
buffering. It is very important for the front end to decouple the back
end from the client's pipe, so as to allow the two layers to scale
independently. I realize that one can just as easily tweak the kernel's
socket buffer size, but I believe there are smarter ways to go about
that.
The current choice of Apache or Squid for a load-balance, failing-over,
buffering, caching HTTP accellerator are unsatisfactory. In high
performance situations I find myself rolling my own. The most daunting
thing about that is of course handling the HTTP protocol itself, where I
rely on the philosophy of passing everything verbatim to the backend
Apache and doing whatever it does, which also doubles as free keep-alive
logic.
I would be very pleased to see some kind of libapachehttp for the
protocol, libapacheio for async Fu, and something very like squid's
redirector interface for implementing load balancing, failover, and
urlspace logic. SSL is a bonus that can already be lifted from openssl,
and I can personally do without caching altogether.
Context: I am much more interested in using HTTP as an application
protocol between remote clients and my application server than I am in
delivering HTML documents. The two have very different requirements in
that a pure application server generally doesn't generate anything
cachable and doesn't serve static files of any kind.
Cheers,
Jeffrey
Re: HTTP + XML + SCP = HTTP/ng
Posted by Dean Gaudet <dg...@arctic.org>.
bleh, i'm on neither, tomcat-dev@tomcat.apache.org, nor
jserv-dev@list.working-dogs.com... so if folks want those other folks
still in on this thread then could someone please forward? thanks.
Dean
On Thu, 10 Feb 2000, Dean Gaudet wrote:
> On Mon, 7 Feb 2000, Martin Pool wrote:
>
> > Given the state of Java and HTTP today I wonder whether it would be
> > better to build a toolkit of Java classes for building HTTP servers,
> > rather than using AJP to plug into Apache.
>
> that's what i was advocating.
>
> > Where's Apache going to go in the future? Is it going to be a single
> > big do-everything program, or a cluster of complementary projects?
>
> i hope not, but unfortunately there's a little bit of momentum... i've
> made a couple attempts to suggest ways we could split it up. but i don't
> have the energy to evangelise the topic.
>
> so one of the points i brought up earlier in the thread hasn't been
> addressed: what problems are people trying to solve?
>
> the web applications of which i'm aware are essentially composed of:
>
> - static content
> - dynamic content which is cacheable (i.e. almost static)
> - dynamic content which is uncacheable
>
> the best url design includes all these components under the same hostname.
> so either all the services end up on one box, or some sort of front-end is
> required.
>
> both apache and squid perform as front-ends today.
>
> if we had a front-end server with the following feature set:
>
> - full HTTP/1.1 proxy cache
> - HTTP/1.1 server capable of serving static files
> - uses async i/o at least for serving static files (which includes
> files in the proxy cache)
> - capable of dividing the urlspace amongst different pools of
> backend servers
> - capable of load balancing amongst several backends within a pool
> - handles persistant/pipelined connections with clients and with
> backends
> - SSL
>
> in this scenario i would expect the back-ends to talk http. the front-end
> would parse the incoming request and either handle it from disk/cache, or
> pass it through to a back-end.
>
> then i'd really like to know what applications can't be solved? real
> world examples please, you know how much of a pain i am :)
>
> i mean i can think of some. consider authentication. you might want your
> entire urlspace to live behind an auth method which you want to implement
> in java to talk to your databases in some way. but you've got portions of
> your urlspace served by static files, some served by perl, and some served
> by java.
>
> well, the front-end could make a SOAP request (XML over HTTP) to your java
> back-end, and presumably your java back-end can return a response which is
> temporarily cacheable. the front-end keeps that in its proxy cache...
> (or heck it could just proxy a HEAD request... my point is that it can
> just pass the entire client request to the backend.)
>
> anyhow we could go through each phase of the current module API and come
> up with an application... but when i sit down and think about these things
> i frequently find myself showing that a particular api phase just isn't
> needed.
>
> aren't the php and java back-ends just content handlers today? they don't
> even touch other API phases right?
>
> i honestly don't see the point of CORBA, or any of the other binary
> protocols.
>
> - they require more code, which clobbers L1 cache efficiency (which i'm
> willing to bet will eliminate any perceived benefit you're hoping for by
> making things binary)
>
> - they require us to document the interfaces and be careful about defining
> semantics... whereas HTTP/1.1 proxying is well defined by rfc2616, that
> work is done for us already.
>
> - some of us haven't had the patience to keep up with the object protocol
> acronym soup of the day ;)
>
> - most of us will end up using XML anyhow, and we've already got XML
> libraries in our codebases (this is if we even need SOAP)
>
> - code reuse #1
>
> about the only extension to HTTP which i think we might want to consider
> is Simon Spero's SCP -- session control protocol. (you can find a version
> of it named TMP used without credit in rfc2371). SCP allows you to
> optimise front-end/back-end communications by multiplexing multiple
> streams into one tcp session... big performance boost from this.
>
> HTTP + XML + SCP = HTTP/ng :)
>
> other than C and java libraries implementing SCP, what's missing?
>
> Dean
>
>
HTTP + XML + SCP = HTTP/ng
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 7 Feb 2000, Martin Pool wrote:
> Given the state of Java and HTTP today I wonder whether it would be
> better to build a toolkit of Java classes for building HTTP servers,
> rather than using AJP to plug into Apache.
that's what i was advocating.
> Where's Apache going to go in the future? Is it going to be a single
> big do-everything program, or a cluster of complementary projects?
i hope not, but unfortunately there's a little bit of momentum... i've
made a couple attempts to suggest ways we could split it up. but i don't
have the energy to evangelise the topic.
so one of the points i brought up earlier in the thread hasn't been
addressed: what problems are people trying to solve?
the web applications of which i'm aware are essentially composed of:
- static content
- dynamic content which is cacheable (i.e. almost static)
- dynamic content which is uncacheable
the best url design includes all these components under the same hostname.
so either all the services end up on one box, or some sort of front-end is
required.
both apache and squid perform as front-ends today.
if we had a front-end server with the following feature set:
- full HTTP/1.1 proxy cache
- HTTP/1.1 server capable of serving static files
- uses async i/o at least for serving static files (which includes
files in the proxy cache)
- capable of dividing the urlspace amongst different pools of
backend servers
- capable of load balancing amongst several backends within a pool
- handles persistant/pipelined connections with clients and with
backends
- SSL
in this scenario i would expect the back-ends to talk http. the front-end
would parse the incoming request and either handle it from disk/cache, or
pass it through to a back-end.
then i'd really like to know what applications can't be solved? real
world examples please, you know how much of a pain i am :)
i mean i can think of some. consider authentication. you might want your
entire urlspace to live behind an auth method which you want to implement
in java to talk to your databases in some way. but you've got portions of
your urlspace served by static files, some served by perl, and some served
by java.
well, the front-end could make a SOAP request (XML over HTTP) to your java
back-end, and presumably your java back-end can return a response which is
temporarily cacheable. the front-end keeps that in its proxy cache...
(or heck it could just proxy a HEAD request... my point is that it can
just pass the entire client request to the backend.)
anyhow we could go through each phase of the current module API and come
up with an application... but when i sit down and think about these things
i frequently find myself showing that a particular api phase just isn't
needed.
aren't the php and java back-ends just content handlers today? they don't
even touch other API phases right?
i honestly don't see the point of CORBA, or any of the other binary
protocols.
- they require more code, which clobbers L1 cache efficiency (which i'm
willing to bet will eliminate any perceived benefit you're hoping for by
making things binary)
- they require us to document the interfaces and be careful about defining
semantics... whereas HTTP/1.1 proxying is well defined by rfc2616, that
work is done for us already.
- some of us haven't had the patience to keep up with the object protocol
acronym soup of the day ;)
- most of us will end up using XML anyhow, and we've already got XML
libraries in our codebases (this is if we even need SOAP)
- code reuse #1
about the only extension to HTTP which i think we might want to consider
is Simon Spero's SCP -- session control protocol. (you can find a version
of it named TMP used without credit in rfc2371). SCP allows you to
optimise front-end/back-end communications by multiplexing multiple
streams into one tcp session... big performance boost from this.
HTTP + XML + SCP = HTTP/ng :)
other than C and java libraries implementing SCP, what's missing?
Dean
Re: [Proposal] "Relayed" Apache API Project
Posted by Martin Pool <mb...@linuxcare.com.au>.
On Sun, Feb 06, 2000 at 12:47:45AM -0800, costin@eng.sun.com wrote:
> > >I know almost nothing about Corba so I can't really say anything here.
> > >But if we remove all the Corba-ish stuff from the orb and use IIOP like
> > >we use AJP today, I don't think it's a huge issue.
> >
> > Corba is nothing without the compiled IDL interfaces and object ids.
> > Using IIOP to transmit a fixed subset will simply add overhead to
> > whatever it is that you are sending -- eventually it will encounter
>
> The point is that IIOP is not _so_ complex as a protocol, i.e. CDR is not
> the worst marshaling and it's almost identical with what AJP does ( with
> the difference that it supports more data types - with the added
> complexity).
Mm, but it's still not nearly so simple as HTTP. I really like being
able to ngrep the traffic and immediately see what's happening, netcat
plain-text requests in to port 80 to test, and implement a client in
just a few lines of any language.
More importantly, if the protocol is simple, then it's relatively easy
to write servers that are good at specific tasks: Boa for static
files, a pure-Java system for servlets, Apache for everything else.
It's easy to experiment and prototype and debug.
Given the state of Java and HTTP today I wonder whether it would be
better to build a toolkit of Java classes for building HTTP servers,
rather than using AJP to plug into Apache.
Where's Apache going to go in the future? Is it going to be a single
big do-everything program, or a cluster of complementary projects?
--
Martin Pool, Technical Support Engineer, Linuxcare, Inc.
+61 2 6262 8990
mbp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
Re: [Proposal] "Relayed" Apache API Project
Posted by Rajan <rh...@atlassoft.com>.
What role does a webserver play in the following scenario :
1) An appserver like Netscape application server 4.0, or weblogic 4.5.1 with
the content management done using Servlets and JSP pages.Are the web servers
only used as a HTTP request forwarders to the appservers.
2)Using Tomcat 3.0 as the servlet and JSP engines. Since Tomcat has a
HttpListener of its own is it worthwhile to go in for a webserver like say
Apache Is there any performance issue involved in such a situation ?
Thanks.
arijith
Re: [Proposal] "Relayed" Apache API Project
Posted by co...@eng.sun.com.
> >I know almost nothing about Corba so I can't really say anything here.
> >But if we remove all the Corba-ish stuff from the orb and use IIOP like
> >we use AJP today, I don't think it's a huge issue.
>
> Corba is nothing without the compiled IDL interfaces and object ids.
> Using IIOP to transmit a fixed subset will simply add overhead to
> whatever it is that you are sending -- eventually it will encounter
The point is that IIOP is not _so_ complex as a protocol, i.e. CDR is not
the worst marshaling and it's almost identical with what AJP does ( with
the difference that it supports more data types - with the added
complexity).
Same for GIOP - it may have a header that is too long, but it doesn't add
so much overhead ( vs. AJP or another protocol we might invent over
night).
Probably it's a bad ideea to try to turn apache into a ORB or to expect
interoperability, but instead of inventing our own protocol we might just
use some existing one, and maybe we can achieve some minimal
interoperability.
I don't think the problems are so bad on trivial method calls, with string
parameters.
Regarding IDL, it will be a good ideea to at least define the interfaces
we want to expose ( and IDL is not too bad for that). ( that doesn't mean
to use stubs and all the heavy CORBA, just to have a documented and clear
set of interfaces separated from the protocol instead of defining the API
as a part of the protocol ).
The result will be slower than AJP or any other protocol, but the
difference will not be very big, and on long term it will be easier to
maintain and develop it.
( it's interesting to read about KDE and corba, I think it's a very
interesting experiment !)
Costin
Re: [Proposal] "Relayed" Apache API Project
Posted by co...@eng.sun.com.
> >I know almost nothing about Corba so I can't really say anything here.
> >But if we remove all the Corba-ish stuff from the orb and use IIOP like
> >we use AJP today, I don't think it's a huge issue.
>
> Corba is nothing without the compiled IDL interfaces and object ids.
> Using IIOP to transmit a fixed subset will simply add overhead to
> whatever it is that you are sending -- eventually it will encounter
The point is that IIOP is not _so_ complex as a protocol, i.e. CDR is not
the worst marshaling and it's almost identical with what AJP does ( with
the difference that it supports more data types - with the added
complexity).
Same for GIOP - it may have a header that is too long, but it doesn't add
so much overhead ( vs. AJP or another protocol we might invent over
night).
Probably it's a bad ideea to try to turn apache into a ORB or to expect
interoperability, but instead of inventing our own protocol we might just
use some existing one, and maybe we can achieve some minimal
interoperability.
I don't think the problems are so bad on trivial method calls, with string
parameters.
Regarding IDL, it will be a good ideea to at least define the interfaces
we want to expose ( and IDL is not too bad for that). ( that doesn't mean
to use stubs and all the heavy CORBA, just to have a documented and clear
set of interfaces separated from the protocol instead of defining the API
as a part of the protocol ).
The result will be slower than AJP or any other protocol, but the
difference will not be very big, and on long term it will be easier to
maintain and develop it.
( it's interesting to read about KDE and corba, I think it's a very
interesting experiment !)
Costin