harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
Date Wed, 26 Jul 2006 18:12:26 GMT
Miguel Montes wrote:
> On 7/26/06, Stefano Mazzocchi <stefano@apache.org> wrote:
>> Miguel Montes wrote:
>> > On 7/26/06, Stefano Mazzocchi <stefano@apache.org> 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

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

> 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.



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

View raw message