[
Lists Home |
Date Index |
Thread Index
]
> Perhaps the world was lucky with TCP/IP and HTTP, that there was no
> commercial clamoring for products before the specs were mostly baked. The
> same, for good or bad, can not be said for XML.
Having been around before TCP became welded to IP I can say the good old days
aren't as rosy as that would suggest. It wasn't that simple. And 3com wanting
to utterly gouge for Ethernet didn't help either. It was a period of /at least/
five years that tied up internetworking with technology purist and proprietary
vendor arguments. Had Arcnet not utterly dropped the ball things could well be
different today.
> Making mistakes is a necessary side-effect of developing new technologies.
> Inevitably, some of the XML technologies will be seen as mistakes, but
> it's only after implementation failures that these mistakes are seen,
> yielding better and more appropriate designs..
>
> I'm sure this happened in the early days of TCP/IP, SMTP, escalator
> design, whatever ... -- but we didn't have the whole world (and companies
> with market capitalization well in excess of $100 billion) watching!
> > I personally think that the best *business* strategy is to make sure that
> > you working with just those bits of the Web and XML infrastructure that
> > they can understand and develop with without necessarily
> > requiring the toolkits, and choose toolkit vendors who automate the tedium
> > rather than hiding the architecture of the infrastructure.
In general I'd support that logic. But the state of the toolkits is
inconsistent enought to make it impractical to actually do that today. Despite
what the marketing people would have you believe.
> Basically, the don't want to think too hard about technology -- they want
> the tool developer to do all that for them.
The eternal evil triangle: Good, fast, cheap... pick two.
-Bill Kearney
|
