Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 73888 invoked from network); 26 Jul 2006 18:12:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 26 Jul 2006 18:12:57 -0000 Received: (qmail 78837 invoked by uid 500); 26 Jul 2006 18:12:54 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 78798 invoked by uid 500); 26 Jul 2006 18:12:54 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 78787 invoked by uid 99); 26 Jul 2006 18:12:54 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Jul 2006 11:12:54 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [69.9.190.6] (HELO lox.whirlycott.com) (69.9.190.6) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Jul 2006 11:12:53 -0700 Received: (qmail 9962 invoked by uid 1016); 26 Jul 2006 18:12:31 -0000 Received: from 70.36.208.192 by lox.whirlycott.com (envelope-from , uid 1009) with qmail-scanner-1.25 (clamdscan: 0.87.1/1179. Clear:RC:1(70.36.208.192):. Processed in 0.19417 secs); 26 Jul 2006 18:12:31 -0000 X-Qmail-Scanner-Mail-From: stefano@apache.org via lox.whirlycott.com X-Qmail-Scanner: 1.25 (Clear:RC:1(70.36.208.192):. Processed in 0.19417 secs) Received: from unknown (HELO ?192.168.1.100?) (stefano@ormaz.it@70.36.208.192) by lox.whirlycott.com with ESMTPA; 26 Jul 2006 18:12:31 -0000 Message-ID: <44C7B08A.9090505@apache.org> Date: Wed, 26 Jul 2006 11:12:26 -0700 From: Stefano Mazzocchi User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd? References: <8E389A5F2FEABA4CB1DEC35A25CB39CE181F67@mssmsx411> <9b6bea40607260640r614aa186h6bea246c67e41f21@mail.gmail.com> <44C7929C.4040509@apache.org> <9b6bea40607260953g707421ddn6dd8c2bbaacda298@mail.gmail.com> <44C7A173.80206@apache.org> <9b6bea40607261028q1111ed09pcb696270fc92db61@mail.gmail.com> In-Reply-To: <9b6bea40607261028q1111ed09pcb696270fc92db61@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Miguel Montes wrote: > On 7/26/06, Stefano Mazzocchi wrote: >> >> Miguel Montes wrote: >> > On 7/26/06, Stefano Mazzocchi wrote: >> >> >> >> Miguel Montes wrote: >> >> >> >> > The method is public, so anyone can use it to read his own DTD. >> >> >> >> Wait, what method are we talking about? >> > >> > >> > The method read(DataInputStream). It's poorly documented, but it reads >> a >> > DTD in an unspecified binary format. The default DTD is stored in this >> > format in a file named html32.bdtd (or html401.bdtd, in the case of the >> > recent contribution). >> > As Alexey pointed out, there is no method to write a DTD, so maybe >> nobody >> > uses the method read() anyway. But I see no point in having a public >> method >> > that nobody can use. So I think we can: >> > 1) Ask Sun to release the specification (if there is one) >> > or >> > 2) Figure it out, and document it >> > or >> > 3) Release our own specification >> >> since the method is public and part of javax.swing, we need to implement >> it, but this looks like a mistake or an overlook (and there are no swing >> tests in the TCK anyway so we can do whatever we please). >> >> I think it's safe to try #1 and #2 in parallel with different people. >> Geir can do #1 while you can do #2. >> >> /me loves to delegate ;-) (aka lazy ass mode) >> > Tim suggested NOT trying to figure it out. I would like a bit of > clarification on what are we allowed or not to do. well, according to the DMCA, you might not be allowed to reverse engineer that. But I doubt that Argentina follows USA's DMCA practices. That said, apache is incorporated in the US so those rules apply for the resulting of this project, so we might not be able to accept your contribution if it was performed with an activity that would be considered illegal in the US. that said, we get an intellectual property license at the end of the certification process... which means that we don't have an intellectual property license *now*, but we are using that intellectual property (say, the javadocs) that is owned by Sun as a way to obtain that intellectual property license (by means of passing the certification tests). This recursive process is somewhat screwed up if you ask me, as Sun should grant a "license to implement but not to release" during the stage between requesting a TCK and passing it. But anyway, that method is not tested, so it does *NOT* influences our ability to obtain the right to implement it the way we please. So, from a legal point of view, just returning "BlameSunException" would be just fine. > There are a lot of situations where the specification is ambiguous or > inexistent, and we have to examine the behavior of the RI. I believe there > was some discussion in this list about the protocol used in RMI, which > isn't specified either. >From a moral/political point of view, I think it is better to ask Sun what to do every time we encounter a detail of the RI that is "implemented" but we can't really "reference" because I'm sure Sun would like to know such a hole in their spec coverage (and it's a good service for them and for other JVM implementors). > I think that examining the format of something that is a parameter of a > public method should be allowed, but I won�t do that until I'm sure I'm not > messing up. Let's be safe rather than sorry. I would suggest that we return "MethodNotImplementedException" for now and ask Sun about information on how to implement it. Expect it to get stack in their legal pipe for a long time, though, with a potentially useless outcome. At that point, I suggest we implement our own instead of attempting to reverse engineer something we don't have the rights to reverse engineer. If the implementation of that method is required for the entire HTML swing subsystem to work, I'm with Tim: it's better to write our own than to throw the legal dice. Especially since nobody can make use of that method anyway. Comments? -- Stefano. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org For additional commands, e-mail: harmony-dev-help@incubator.apache.org