harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Miguel Montes" <miguel.mon...@gmail.com>
Subject Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
Date Thu, 27 Jul 2006 19:57:49 GMT
So, it seems there is consensus on the following steps:
1) We ask Sun again about the bdtd specs
2) We do NOT reverse engineer the bdtd
3) We choose a format, and document it.

It also seems that serialization is not the proper way of doing 3), so we
must select a format that doesn't depend on the implementation of, say,
Hashtable, and we remain compatible with future versions of the class
libraries.
What about using ASN.1? We already have a decoder, so it shouldn't be
difficult

On 7/27/06, Ivanov, Alexey A <alexey.a.ivanov@intel.com> wrote:
>
>
> >-----Original Message-----
> >From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >Sent: Wednesday, July 26, 2006 9:08 PM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [classlib][html] Should we try to be binary compatible
> with
> >Sun's bdtd?
> >
> <SNIP>
> >> 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).
>
> This method seems to be undocumented at all until people asked for it
> [1].
>
> >> 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)
>
> We should try this once more (The first attempt was made in [1]).
>
> >> or
> >> 2) Figure it out, and document it
> >> or
> >> 3) Release our own specification
>
> Maybe specification is not the right word here. I believe we _can_
> document which format we use. So that anyone can prepare their own
> archive file with DTD, read it using jx.s.t.html.parser.DTD.read, pass
> it to parser.
>
> >
> >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).
>
> It is not the only place where a public method is present, but it has no
> use because of lack of documentation.
>
> >
> >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)
> >
> >I would suggest against #3: specifications are something that we are
> not
> >tasked to do (even to compensate lack of such), as it might deliver the
> >wrong message.
> >
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4216248
>
> Regards,
>
> --
> Alexey A. Ivanov
> Intel Middleware Product Division
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Miguel Montes

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message