At 10:52 2/2/01 +0100, Ceki Gülcü wrote:
>
>Sorry. I inadvertently pressed Ctrl-e which made Eudora forward my
incomplete note. Here is the complete note.
>
>At 19:19 01.02.2001 -0800, you wrote:
>>on 2/1/01 6:45 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>>
>>> [ Running, ducking, and grinning ;-) ]
>>>
>>> - Sam Ruby
>>
>><loop repeat="infinite">
>><voice tone="robotic">
>> Do not try to resist.
>> We must follow Sun standards.
>> Resistance is futile.
>> J2EE is the only solution.
>> We are Borg.
>> JSP, XML and EJB is the only way.
>> We will assimilate you.
>></voice>
>></loop>
>
>
>There is a lot of insight in this <loop>. Sun is doing a great job at
convincing people to use their technology. This is truly a Herculean task
and imho constitutes a major achievement for Sun.
>
>We should perhaps learn from their JCP model. This is what I *think* they do:
>
>1) Identify a problem area.
>2) Find a number of experts willing to contribute.
>3) Designate a leader.
>
>The ordering of (2) and (3) can be inverted.
>
>4a) Define requirements.
>4b) Consolidate those requirements into a document.
>5a) Define a spec based on the requirements.
>5b) Consolidate the spec into a document.
>5c) Publicize the spec.
>
>Step 5 is iterative.
>
>6a) Quitely write code that implements the spec. Do not release/publicize
this code to avoid the burden of maintenance.
>6b) When ready, release alpha code to select users.
>6c) When ready, release beta to a larger set of users.
>
>7) Take the world by storm when the API+code is ready.
>
>Sun also has an uber-plan consisting of a new release of the JDK. A new
JDK will mass distribute the new APIs so that there will be no point or
very hard to resist any new API. Steps 1 through 6 ensure that the new API
is not botched. (No one will use a manifestly botched API.)
>
>The challenge in this model is to find a competent and respected leader as
well as experts willing to contribute.
I think you overestimate the good naturedness of Sun. Like any other
buisness they are in it for the money. The purpose of the API is generally
not to be the best/good at what it does - that is an ancilliary concern -
the purpose is to establish a standard so that buisnesses can adopt java
and understand which technologies are going to be supported and thus have
easy training/management of such things.
Many of these specs are reactionary to equivelent MS "standards".
Fortunately it now looks like Sun is starting to also work with rather than
against other standardisation groups (ie see JDO and ODMG spec and other
interaction with the OMG etc).
Sun also does not accept things that would threaten it's vision (ie
lightweight clients powered by super computers). Consider the case of
select() style functionality - why has not that been added. It's not
because it isn't portable, nor is it because it is technically hard or a
design challenge. I put it to you that the sole reason is because it would
mean that low end servers with a small number of CPUs could actually start
to compete with the suns network OS hardware which would be a bad thing for
them. Yet not having this functionality has proved considerably challenging
to anyone running java as server and in native threads mode. I suspect this
will change with Merlin release as more people were allowed to have an
opinion.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
