Re[2]: Is "simplicity" a useful architectural constraint?

On Thursday, January 03, 2002, 2:41:41 AM, Scott wrote:


SP> I think simplicity is very important. Maybe it can be measured in
SP> how long it takes to write an app to support  the protocol or
SP> format.

I agree that is a useful metric, though that depends on how isolated
the problem is. To take an example - P3P can be added to a browser
easily because it is well isolated, wheras adding conformance for one
CSS property requires altering ad-hoc rendering code that is poorly
described but affects gazillions of broken HTML pages.

SP> At the moment you can write a basic HTTP server that works with all 
SP> browsers in a day.

Yes but it will be an HTTP 0.9 server. 1.0 added useful stuff and so
did 1.1 and then you need https and logging and if you want efficiency
under high load .... in other words there is a difference between a
tiny server that sits in an inkjet printer and says how much ink is
left, and a big server that handles a major news site with flash
floods and user tracking and targetted advertizing.

That demonstrates that there is a useful profile or subset of HTTP
that can solve a bunch of problems, not that there is not a need for
the full thing

SP> HTML renderer is a little more complicated, but if you are happy
SP> with  text, you can also do that as an individual in days of time
SP> (a subset of course).

Well, perhaps. I would be happier if you said an XHTML + CSS1
renderer, with no requirement to render invalid/nonwellformed/garbage
far less a requirement to render said garbage pixel perfect to its
competing products.

SP> What I like to see in a protocol/format is the ability for it to be 
SP> simple and have optional additional complexity, but be backwards 
SP> compatible for both client and server.

Thats good if the 80/20 rule applies, and 80% of uses are covered by
the 20% simple subset. It becomes a problem if vendor A implements the
core plus modules 1,3,6, 9 and 13 and vendor B implements core plus 1,
3, 5, 6, and 11 and a particular piece of functionality can be
achieved by content creators either with modules 6 and 13 or, in a
different but roughly equivalent way, with modules 5 and 11, so all
content starts with some script to say "if vendor==A then...."

SP> I don't know, maybe the ability to keep it backwards compatible for 
SP> simple and complex browsers and servers actually adds complexity.

After a certain point then yes, it does as the number of cases
multiplies and content has to either cover all the permutations or
else be custom generated based on capabilities and so on.

SP> BTW. I love that I can write into my embedded apps a simple web server 
SP> that generates some simple HTML and point any browser at it. It is an 
SP> fantastic feature that must be maintained.

I agree on the utility of an interoperable core. But I don't think
(nor, its seems were you sugesting) that removes the need for the rest
of the specification.

 --
 Chris

Received on Friday, 4 January 2002 07:30:14 UTC