On Wed, 19 Apr 1995, jon r. luini wrote:
> i think it's a ripe time for being able to include some standard methods
> in building some nice extendibility for the future now in something like
> apache.
"Extending" and "Standard" are sorta mutually exclusive :) Actually
there is a proposal for an extension system in HTTP itself, but Roy
(HTTP-ra) has noted problems in it. But hopefully there'll be something
soon like that.
> i'm not familiar with how involved the apache development crew
> is in trying to extend the HTTP spec and how far it's planned to go without
> touching the spec.
I think the goals are, in my mind at least:
1) Follow the 1.0 spec as closely as possible - as we've found with content
negotiation and other things, there's actually some pretty cool shite in
there that if more sites supported could really advance things.
2) Test out an implementation of 1.1 - I'm particularly interested in the
SESSION method whereby multiple GETs could be issued in one transaction.
3) Maybe go to HTTP-NG - though I have a feeling we might not see a
benefit from that with the current code base and the single-threading
architecture. Maybe we can cannibalize Apache (oh, god, bad word choice)
and stick its functions onto something like MDMA.
> i'm curious whether there are already plans for the
> netsite-ish push/pull strategies
Those are mostly external to HTTP. For client pull, you need to be able
to send the "Refresh:" header, which while not a standard HTTP header
isn't illegal (much less offensive than extraneous netscape tags :). You
can do this with an .asis file type. For server push, it's up to the
server application developer to build code that just sends Multipart
snippets at timed intervals. I can see gross abuse of these functions in
applications that either don't really need it (animation) or can be done
more efficiently otherwise.
> and communication with passing URL's
> and data to open pipes between companion applications.
For the client side, you're talking about their proprietary API which
uses OLE, AppleEvents, or XEvents depending on the platform. If you mean
their server, you're again talking about a proprietary API. The server
API looked rather interesting, and perhaps deserves an RFC or
standardization of its own amongst server developers, and we'd certainly
support that effort. We're not going to try and compete against Netscape
feature-for-feature (I'm sure Rob M.'s not worried, at least! :) of
course.
> there are people
> all over the place doing various extensions based on specific mime-types
Extensions to the server based on MIME types? Yup, I know we've extended the
"feature" of NCSA's httpd in polluting the MIME namespace for server-based
functions, something I'd like to see die but I know can't for political
reasons until we make a clear break from NCSA-style configuration files.
> as well as moving into non-scalable server-modification solutions
Hmm?
> and i'd
> like to see all of that be able to come under one roof so as to reach the
> widest audience being able to benefit from such extensions.
Clearly there is a need for Netscape, Spry, Navisoft, NCSA, W3O, and
other companies working on servers to come together and discuss API's and
such and decide on a common architecture - but I wouldn't bank on
anyone's becoming a standard any time soon. If something's not a
standard, our criteria for implementing it will be based on whether or
not we think it's a good idea.
> obviously, a lot of this ends up being on the client side, but it seems
> to me that if you build a back-side standard, the folks making the browsers
> will jump at incorporating new standards (hence my veering off in the previous
> paragraph about the HTTP spec).
Hmm - I'd think they could be as orthogonal as possible, hopefully.
Yeah, developing HTTP is going to be a chicken and egg situation, but
hopefully Java can alleviate that. It's my opinion that companies should
be working to make the browsers as smart as possible, as
component-ware-able as possible, and the servers should just do the job
they do well, which is pump out well-typed information.
> none of this message is really designed for much in the way of specific
> responses, which is mostly intentional since i know apache is nearing beta.
> i just wanted to toss a couple things out there and if people are interested
> in talking more about it we could do so in a smaller list or later when
> it doesn't get in the way of the current traffic.
No, I love bullshitting about this kind of stuff. I think it helps us
define why we're here :)
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com
http://www.[hyperreal,organic].com/