At 10:23 08.03.2001 -0500, Steve Downey wrote:
>Standard and open have historically had a very small intersection. Most ANSI
>and ISO standards cost thousands of dollars per copy.
I agree.
>IAC, Java is not a standards based language. It's a succesful vendor defined
>language. With any meaningful definition of standard, the only interfaces
>that meet it are the CORBA bindings and the xml ones under org.w3c.
>
>I assume the definition sought here is the inverse of the US definition of
>obscenity?
>
>What about (eg one defined through the JCP, or by the OMG, or by the W3C, or
>other similar body)
The JCP is not a very open way of defining a "standard" API. It has quite a high
barrier of entry and most important decisions are made by the "specification leader."
Very few committee driven processes actually deliver palatable results. If they do
deliver, usually the process is not very "democratic" nor open. As far as I know, the
most successful standardization body is the Internet Society (http://www.isoc.org/) in
particular the IETF. It would be worthwhile to study the way they function.
Coming back to the JCP, it is pretty clear that Sun dominates it. No need to be a
rocket scientist there. The APIs that result from the various JSR API are usually
reasonable but they do not necessarily provide the best solution to a given problem.
As such, there is no need to say Amen to every utterance made by Sun.
The Apache Software Foundation is a very influential group. The opinion of the ASF
actually makes a difference. That is probably one of the reasons why big companies
such as Sun and IBM are heavily involved in the various ASF projects. (Disclaimer: I
am not saying that the individual participants from those companies are not dedicated
to the ASF or open source software. What I am saying is that those big companies
support the work of their employees participating in the ASF so as not to be excluded
from the game.)
It would be stupid to reject the results of a given JSR API on the sole basis that the
JCP is dominated by Sun. It would be just as wrong to blindly adopt a given JSR API as
the "standard" because it's part of a future JDK. For example, not every API defined
in MS Windows is a standard. They just happen to be part of the OS.
To summarize, I think that as an organization we should consider APIs on the basis of
their merit and their respective advantages/disadvantages. Saying that we should adopt
API XYZ just because it is Sun sponsored is not the wisest way to proceed. Regards,
Ceki
>-----Original Message-----
>From: Jon Stevens [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, March 07, 2001 1:58 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [PROPOSAL] The Commons
>
>
>on 3/7/01 5:21 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
>
>> How about:
>>
>> 7. In general, packages should provide an interface and one or more
>> implementations of that interface, or implement another standard
>> interface (e.g. one defined by Sun).
>
>-1
>
>I don't like the implication that something defined by Sun is a standard.
>
>To me, a standard is something that is open. Sun isn't open.
>
>-jon
>
>--
>If you come from a Perl or PHP background, JSP is a way to take
>your pain to new levels. --Anonymous
><http://jakarta.apache.org/velocity/ymtd/ymtd.html>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
><><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
>may contain confidential information and is intended only for the person(s)
>named. Any use, copying or disclosure by any other person is strictly
>prohibited. If you have received this transmission in error, please notify
>the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: [EMAIL PROTECTED] (preferred)
CH-1005 Lausanne [EMAIL PROTECTED]
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
