Erik Funkenbusch wrote:
> On 15 Oct 2006 08:57:32 -0700, Roy Schestowitz wrote:
>
> > Firefox 2.0 to Feature New JavaScript 1.7
> >
> > http://www.betanews.com/article/Firefox_20_to_Feature_New_JavaScript_17/1160795703
>
> Firefox adopts new non-standard version of ECMA-script. Claims it's
> supporting standards.
Actually, it's a natural progression. Often, the last stage before
adoption as a standard, is the implementation, based on the
specifications, in Open Source. This proves that the standard is
functional, implementable, and complete.
Traditionally, the implementation would be done using college students,
preferably undergraduates, to make sure that the technology could not
be patented. The other alternative is to include provisions in the OSS
license which wave or nullify any subsequent patentability claims by
the implementors.
Keep in mind that the primary function of standards is to generate the
agreement of many different parties.
You need the agreement of publishers, not just of the standards
themselves, but also of those tools, applications, and services based
on that standard. Microsoft says "we ARE the standard", yet makes no
attempt to get agreement from it's competitors.
You need the agreement of customers, those using the standards must be
confident that they can get support and compliant products from
numerous alternate sources. Again, Microsoft makes no attempt to
provide this assurance. Hence, Microsoft's "standard" is not a
standard, simply an expression of an intent to establish or extend a
monopoly.
You need the agreement of the support community, those who must
install, manage, configure, maintain, and support the foundation
standards. These people look to standards to provide interoperability
between their company's customers, suppliers, vendors, regulators, and
even their competitors. Microsoft does provide excellent support for
installation - having the most strategic technology simply preinstalled
by the OEMs. Other Microsoft software is designed to be extremely easy
to install. But this is where it ends.
To manage software, you must be able to remove, downgrade, and manage
software and upgrades, especially when these upgrades, enhancements,
adversely affect your ability to interact with the parties listed
above. Removing software from Windows is a very 'high risk' venture.
In most cases, the system can quickly become so corrupted that the only
option is to reimage the entire hard drive.
The ISO/OSI debacle shows what happens when one tries to define a
"standard" based on proprietary technology, especially the proprietary
technology of multiple vendors. TCP/IP wasn't as effecient as CNLS,
but it was implemented in Opens Source (BSD) source code, and could be
ported to any machine capable of running a C compiler. Conversely, the
OSI standards were a hodgepodge of SNA, DECNet, NetWare, and protocols
long since dead and buried. Just the MANUALS totaled over $50,000 per
reader, and even though all of the proprietary vendors claimed to be
"OSI Compliant", users of DecNet couldn't talk to SNA and users of
NetWare couldn't talk to either. As a "Standard" OSI was a joke, but
most of the industry wasn't laughing.
Eventually some standards from OSI, such as Kerberos and LDAP, were
adopted, but only after formalization and publication by the IETF (who
did not charge for the detailed specifications) and subsequent
publication in Open Source licensed software, usually BSD or GNU or
MIT/X11.
With the "reference models" implemented, it was up to each vendor
whether they wanted to implement a totally proprietary implementation,
or whether they wanted to simply use the reference implementation and
"enhance" it by adding user-friendly configuration tools. Because the
standards were subject to changes, and often reeded to be backward
compatible, most vendors quickly decided the option of using the BSD
licensed reference implementation and adding tools to manipulate the
standard configuration files, was far easier to manage over time.
Although supersets or extensions were possible, undocumented and
standards not implemented in BSD or similar OSS software, were almost
always frowned upon, and usually ended up dissappearing due to lack of
support.
Microsoft has promised to comply with standards, including TCP/IP,
LDAP, CORBA, and numerous others, only to corrupt the standards with
their own proprietary extensions. The end result has almost always
been problems with security, support, interoperability, and ultimately,
agreement between all of the parties listed above.
SMB was incompatible with NFS, TCP/IP based on DHCP was incompatible
with more controlled systems such as RARP and dynamic RARP, WINS was
incompatible with DNS, NetBIOS was incompatible with almost everything
but Windows. ActiveDirectory was incompatible with LDAP (without
special patching to one of the two), Microsoft's RPC was incompatible
with both DCE and RPC. Their DCOM was initially incompatible with
CORBA.
In some cases, the industry has attempted to accomodate the hundreds of
millions of Microsoft Windows users, but often at the known risk of
loss of security, of other serious problems, and almost always without
the permission or acceptance of Microsoft.
It was Mosaic that set the standards. Microsoft licensed it, tried to
extend the standards, but even today, many corporations disable
Microsoft extensions such as ActiveX controls, or strictly limit it's
use.
|
|
