● Apache之父4月11日演讲主要内容(2) - 荔园在线 | 深圳大学学生论坛,荔园晨风BBS,深大在线网站

荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀

发信人: gxq.bbs@siyu.dhs.org (逍遥游), 信区: Linux
标题: Apache之父4月11日演讲主要内容(2)
发信站: 思雨小语 (Fri May 9 11:45:45 2003)
转信站: SZU!news.tiaozhan.com!Siyu

It's All About Platforms
While I'm indeed a big fan of the open-source approach to software development,
there are definitely situations where an open-source approach would not benefit
the parties involved. There are strong tradeoffs to this model, and returns are
never
guaranteed. A proper analysis requires asking yourself what your goals as a
company are in the long term, as well as what your competitive advantages are
today.

Let's start first with a discussion about Application Programming Interfaces
(APIs), platforms, and standards. For the purposes of this essay, I'll wrap
APIs (such as the Apache server API for building custom modules), on-the-wire
protocols like HTTP,
and operating system conventions (such as the way Linux organizes system files,
or NT servers are administered) into the generic term ``platform.''

Win32, the collection of routines and facilities provided and defined by
Microsoft for all Windows 95 and NT application developers, is a platform. If
you intend to write an application for people to use on Windows, you must use
this API. If you
intend, as IBM once did with OS/2, to write an operating system which can run
programs intended for MSWindows, you must implement the Win32 API in its
entirety, as that's what Windows applications expect to be able to use.

Likewise, the Common Gateway Interface, or ``CGI,'' is a platform. The CGI
specification allows web server developers to write scripts and programs that
run behind a web server. CGI is a much much simpler platform than Win32, and of
course does much
less, but its existence was important to the web server market because it
allowed application developers to write portable code, programs that would run
behind any web server. Besides a few orders of magnitude in complexity, a key
difference between
CGI and Win32 was that no one really owned the CGI specification; it was simply
something the major web servers implemented so that they could run each others'
CGI scripts. Only after several years of use was it deemed worthwhile to define
the CGI
specification as an informational Request for Comments (RFCs) at the Internet
Engineering Task Force (IETF).

A platform is what essentially defines a piece of software, any software, be it
a web browser like Netscape, or be it Apache. Platforms enable people to build
or use one piece of software on top of another, and are thus essential not just
for the
Internet space, where common platforms like HTTP and TCP/IP are what really
facilitated the Internet's explosive growth, but are becoming more and more
essential to consider within a computer environment, both in a server context
and in an end-user
client context.

In the Apache project, we were fortunate in that early on we developed an
internal API to allow us to distinguish between the core server functionality
(that of handling the TCP connections, child process management, and basic HTTP
request handling)
and almost all other higher-level functionality like logging, a module for CGI,
server-side includes, security configuration, etc. Having a really powerful API
has also allowed us to hand off other big pieces of functionality, such as
mod_perl (an
Apache module that bundles a Perl interpreter into Apache) and mod_jserv (which
implements the Java Servlet API), to separate groups of committed developers.
This freed the core development group from having to worry about building a
``monster'' to
support these large efforts in addition to maintaining and improving the core
of the server.

There are businesses built upon the model of owning software platforms. Such a
business can charge for all use of this platform, whether on a standard
software installation basis, or a pay-per-use basis, or perhaps some other
model. Sometimes
platforms are enforced by copyright; other times platforms are obfuscated by
the lack of a written description for public consumption; other times they are
evolved so quickly, sometimes other than for technical reasons, that others who
attempt to
provide such a platform fail to keep up and are perceived by the market as
``behind'' technologically speaking, even though it's not a matter of
programming.

Such a business model, while potentially beneficial in the short term for the
company who owns such a platform, works against the interests of every other
company in the industry, and against the overall rate of technological
evolution. Competitors
might have better technology, better services, or lower costs, but are unable
to use those benefits because they don't have access to the platform. On the
flip side, customers can become reliant upon a platform and, when prices rise,
be forced to
decide between paying a little more in the short run to stick with the platform,
or spending a large quantity of money to change to a different platform, which
may save them money in the long run.

Computers and automation have become so ingrained and essential to day-to-day
business that a sensible business should not rely on a single vendor to provide
essential services. Having a choice of service means not just having the
freedom to choose; a
choice must also be affordable. The switching cost is an important aspect to
this freedom to choose. Switching costs can be minimized if switching software
does not necessitate switching platforms. Thus it is always in a customers'
interests to demand
that the software they deploy be based on non-proprietary platforms.

This is difficult to visualize for many people because classic economics, the
supply and demand curves we were all taught in high school, are based on the
notion that products for sale have a relatively scalable cost -- that to sell
ten times as much
product, the cost of raw goods to a vendor typically rises somewhere on the
order of ten times as well. No one could have foreseen the dramatic economy of
scale that software exhibits, the almost complete lack of any direct
correlation between the
amount of effort it takes to produce a software product and the number of
people who can thus purchase and use it.

A reference body of open-source software that implements a wire protocol or API
is more important to the long-term health of that platform than even two or
three independent non-open-source implementations. Why is this? Because a
commercial
implementation can always be bought by a competitor, removing it from the
market as an alternative, and thus destroying the notion that the standard was
independent. It can also serve as an academic frame of reference for comparing
implementations and
behaviors.

There are organizations like the IETF and the W3C who do a more-or-less
excellent job of providing a forum for multiparty standards development. They
are, overall, effective in producing high-quality architectures for the way
things should work over
the Internet. However, the long-term success of a given standard, and the
widespread use of such a standard, are outside of their jurisdiction. They have
no power to force member organizations to create software that implements the
protocols they
define faithfully. Sometimes, the only recourse is a body of work that shows
why a specific implementation is correct.

For example, in December of 1996, AOL made a slight change to their custom HTTP
proxy servers their customers use to access web sites. This ``upgrade'' had a
cute little political twist to it: when AOL users accessed a web site using the
Apache 1.2
server, at that time only a few months old and implementing the new HTTP/1.1
specification, they were welcomed with this rather informative message:

UNSUPPORTED WEB VERSION
The Web address you requested is not available in a version supported by AOL.
This is an issue with the Web site, and not with AOL. The owner of this site is
using an unsupported HTTP language. If you receive this message frequently, you
may want to
set your web graphics preferences to COMPRESSED at Keyword: PREFERENCES
Alarmed at this ``upgrade,'' Apache core developers circled the wagons and
analyzed the situation. A query to AOL's technical team came back with the
following explanation:
New HTTP/1.1 web servers are starting to generate HTTP/1.1 responses to
HTTP/1.0 requests when they should be generating only HTTP/1.0 responses. We
wanted to stem the tide of those faults proliferating and becoming a de facto
standard by blocking
them now. Hopefully the authors of those web servers will change their software
to only generate HTTP/1.1 responses when an HTTP/1.1 request is submitted.
Unfortunately AOL engineers were under the mistaken assumption that HTTP/1.1
responses were not backward-compatible with HTTP/1.0 clients or proxies. They
are; HTTP was designed to be backward-compatible within minor-number revisions.
But the
specification for HTTP/1.1 is so complex that a less than thorough reading may
lead one to have concluded this was not the case, especially with the HTTP/1.1
document that existed at the end of 1996.
So we Apache developers had a choice -- we could back down and give HTTP/1.0
responses to HTTP/1.0 requests, or we could follow the specification. Roy
Fielding, the ``HTTP cop'' in the group, was able to clearly show us how the
software's behavior at
the time was correct and beneficial; there would be cases where HTTP/1.0
clients may wish to upgrade to an HTTP/1.1 conversation upon discovering that a
server supported 1.1. It was also important to tell proxy servers that even if
the first request
they proxied to an origin server they saw was 1.0, the origin server could also
support 1.1.

It was decided that we'd stick to our guns and ask AOL to fix their software.
We suspected that the HTTP/1.1 response was actually causing a problem with
their software that was due more to sloppy programming practices on their part
than to bad
protocol design. We had the science behind our decision. What mattered most was
that Apache was at that point on 40% of the web servers on the Net, and Apache
1.2 was on a very healthy portion of those, so they had to decide whether it
was easier to
fix their programming mistakes or to tell their users that some 20% or more of
the web sites on the Internet were inaccessible through their proxies. On
December 26th, we published a web page detailing the dispute, and publicized
its existence not
just to our own user base, but to several major news outlets as well, such as
C|Net and Wired, to justify our actions.

AOL decided to fix their software. Around the same time, we announced the
availability of a ``patch'' for sites that wanted to work around the AOL
problem until it was rectified, a patch that degraded responses to HTTP/1.0 for
AOL. We were resolute
that this was to remain an ``unofficial'' patch, with no support, and that it
would not be made a default setting in the official distribution.

There have been several other instances where vendors of other HTTP products
(including both Netscape and Microsoft) had interoperability issues with Apache;
in many of those cases, there was a choice the vendor had to make between
expending the
effort to fix their bug, or writing off any sites which would become inoperable
because of it. In many cases a vendor would implement the protocol improperly
but consistently on their clients and servers. The result was an implementation
that worked
fine for them, but imperfectly at best with either a client or server from
another vendor. This is much more subtle than even the AOL situation, as the
bug may not be apparent or even significant to the majority of people using
this software -- and
thus the long-term ramifications of such a bug (or additional bugs compounding
the problem) may not be seen until it's too late.

Were there not an open-source and widely used reference web server like Apache,
it's entirely conceivable that these subtle incompatibilities could have grown
and built upon each other, covered up by mutual blame or Jedi mind tricks (``We
can't repeat
that in the lab... .''), where the response to ``I'm having problem when I
connect vendor X browser to vendor Y server'' is, ``Well, use vendor Y client
and it'll be all better.'' At the end of this process we would have ended up
with two (or more)
World Wide Webs -- one that was built on vendor X web servers, the other on
vendor Y servers, and each would only work with their respective vendors'
clients. There is ample historic precedence for this type of anti-standard
activity, a policy
(``locking in'') which is encoded as a basic business practice of many software
companies.

Of course this would have been a disaster for everyone else out there -- the
content providers, service providers, software developers, and everyone who
needed to use HTTP to communicate would have had to maintain two separate
servers for their
offerings. While there may have been technical customer pressure to ``get along
together,'' the contrary marketing pressure to ``innovate, differentiate, lead
the industry, define the platform'' would have kept either party from
attempting to
commodify their protocols.

We did, in fact, see such a disaster with client-side JavaScript. There was
such a big difference in behavior between different browsers, even within
different beta versions of the same browser, that developers had to create code
that would detect
different revisions and give different behavior -- something that added
significantly more development time to interactive pages using JavaScript. It
wasn't until the W3C stepped in and laid the groundwork for a Document Object
Model (DOM) that we
actually saw a serious attempt at creating a multiparty standard around
JavaScript.

There are natural forces in today's business world that drive for deviation
when a specification is implemented by closed software. Even an accidental
misreading of a common specification can cause a deviation if not corrected
quickly.

Thus, I argue that building your services or products on top of a
standards-based platform is good for the stability of your business processes.
The success of the Internet has not only shown how common platforms help
facilitate communication, it has
also forced companies to think more about how to create value in what gets
communicated, rather than trying to take value out of the network itself.

--
※ 来源:·兰大思雨站 siyu.dhs.org·[FROM: 202.201.11.130]

荔园在线首页友情链接：深圳大学深大招生荔园晨风BBS S-Term软件网络书店