Re: FYI, tag election links

Brian Kardell wrote:
> 
> >
> > These are rather historic shifts (in the Web's short history) and
> > have impact far beyond my technical description. And web
> > architecture as documented in AWWW has been proven to scale rather
> > well, and support a particular kind of innovation that has spawned
> > remarkable economic growth.
> >
> 
> Would you be willing to clarify some on what you are saying above?  I
> might just be missing it...
> 

If I may, I'd like to address "proven to scale" from a different
perspective than John's response.

The proof, to me, is that IPv4 lingers on when the early Web was gonna
kill it -- despite sustained exponential growth of the Web; and that my
knowledge of why this is so has allowed me to dismantle expensive CDN/
accelerator deployments in favor of KISS and HTTP caching, improving
user-perceived performance, leading to a surge in visitors without any
site redesign beyond URI allocation scheme (proof's in the pudding).

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

That's the massively peer-reviewed theory which explains, in terms of
networked-software architectural styles, both the failure of the early
Web and the success of the modern Web, as well as where the former has
carried over into the latter.  It served as the model for going from
HTTP 0.9 to 1.1bis, and from the early URI RFCs to 3986.

AWWW != REST and vice-versa, but there's the foundational work which
establishes the resource/representation/identifier basis of HTTP and
URI as they exist today.  Not often is the _evolution_ of a technology
so soundly rooted in peer-reviewed science establishing how and why it
was capable of truly astonishing proliferation without collapsing in a
heap of smoking ruin.  AWWW instantiates REST as it exists in practice
with the protocols we have, making the fundamentals more approachable
to Web developers in terms of practical advice, despite its
shortcomings.

My first exposure to REST was back in my ISP days, after being exposed
to squid to squeeze more out of my T1 lines, and seeking to apply my
HTTP knowledge to my Web work.  Back then it was "HTTP Request Object"
and I used it to code a SSJS CMS for a multinational; used PUT and
DELETE if you had >gasp< Netscape Communicator installed.  But I came
to REST as an httpd sysadmin looking to implement conneg as a solution
to real-world problems with poorly-maintained websites I was hosting.
When another developer introduced me to AWWW, I was like, "Ah, REST."

> 
> If you follow the guys I endorse -- it's easy to see that like me,
> they love the Web (and W3C).
>

I think we're all coming from the same place, and I don't think anyone's
unreceptive to the notion of TAG reform; nor do I think anyone's trying
to disparage previous members or work of TAG... except maybe HTTP-Range-
14, heheh...  I know I'm not inherently opposed to TAG reform, Web Apps
or javascript -- it's just that I have a lot of respect for the work of
others which I've managed to build a comfortable living around for two
decades, and not because they were wrong.

>
> I think TAG is an excellent place to spark the fire and fan the
> flames that will help that happen - and (obviously) that my slate of
> candidates are the best choice to help that happen - they are smart,
> they are excellent evangelists, incredibly involved and exceptionally
> knowledgable and they have little to no baggage to make me think
> otherwise.
> 

Well, hopefully not that kind of flames, and it certainly isn't my
intent to disparage any candidates individually or as a slate.  But, I
do take exception not to the "That's just how we roll" response I
received off-list from one TAG candidate, to the concerns I expressed
here...

http://lists.w3.org/Archives/Public/www-tag/2012Jan/0174.html

...but to that attitude in general, as not exhibiting much wisdom in
regards to guiding the evolution of a globally-distributed system which
has its basis in accepted science.  I would think, that before we talk
about changing the nature of the architecture of the Web, we'd have
equally sound guidance down that road in the form of peer-reviewed
falsification of REST.

Or, extension of it, articulated in AWWW Volume 2:  Web Applications,
with some practical guidance on how sometimes, it may be better to
follow Volume 1 instead of giving my browser's back button five seconds
of pointless latency for something that doesn't need to be implemented
as JS anyway, and would reload faster from the origin if only they'd
just let it.  There's plenty of sound architectural advice just waiting
to be given, if we don't reject it out-of-hand.

Or, am I the only one who's noticed a general degradation in user-
perceived performance and robustness with Web Applications?  Either
these foibles will go away as implementations improve, or maybe they
won't if they're mismatches with an architectural model reflecting the
realities of the network.  Regardless of whether that model is REST, an
extension of REST, or a rejection of it, I believe there needs to be a
model -- based on peer review rather than winging it by committee, aka
"we're the (current) TAG and you're not."

-Eric

Received on Friday, 14 December 2012 04:42:10 UTC