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 Wed, 02 Aug 2006 16:40:19 GMT
As I suggested earlier, I would use ASN.1. I don't like it, but there are
several arguments for using it:
1) We can make a formal description of the format, so anyone can write his
own encoder/decoder. Something like:

BDTD ::= SEQUENCE {
       Entity SET OF HTMLEntity,
       Element SET OF HTMLElement
}

HTMLEntity ::= SEQUENCE {
       Name NameId,
       Type HTMLEntityType,
       Data OCTET STRING
}

NameId ::= OCTET STRING
2) We already have an ASN.1 encoder/decoder, developed by the people of
Intel Middleware Product Division (Stepan and others). It is used in the
crypto framework, so it must be included in Harmony, anyway.

It's complex, and it's not pretty. I wouldn't suggest it if we didn't
already have the decoder available. But it is there, and we can use it.


On 8/2/06, Ivanov, Alexey A <alexey.a.ivanov@intel.com> wrote:
>
> Diego,
>
> I tried to read this file using both J9 and DRLVM, and I didn't manage.
> Hence using serialization is not the best approach, and we need to
> choose another archive format.
>
> Serialization might fail because it contains some classes which
> serialized form is not specified (Element, Entity etc.) and which don't
> contain serialVersionUID field.
>
> We may use DataOutputStream methods to save the required information,
> and directly use DataInputStream to read it. (However using
> serialization looks simpler.)
>
>
> Any ideas about the binary format?
>
> Regards,
> --
> Alexey A. Ivanov
> Intel Middleware Product Division
>
>
> >-----Original Message-----
> >From: Diego Mercado [mailto:mercadodiego@gmail.com]
> >Sent: Wednesday, August 02, 2006 1:36 AM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [classlib][html] Should we try to be binary compatible
> with
> >Sun's bdtd?
> >
> >HARMONY-948 has a serialized dtd file called transitional401.bdtd.
> >When I try to read it by calling DTD.read(DataInputStream) I get a
> >java.io.EOFException. But, on the other hand, when I create a binary
> >DTD by calling DTDUtilities.create(String) I can get it with succeed.
> >
> >How can I read transitional401.bdtd file? I used the JRE Harmony
> >424571 release in GNU/Linux.
> >
> >Thanks,
> >
> >Diego Mercado
> >
> >On 7/28/06, Miguel Montes <miguel.montes@gmail.com> wrote:
> >> On 7/28/06, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> >> >
> >> > On 7/28/06, Miguel Montes wrote:
> >> > >
> >> > > 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
> >> >
> >> >
> >> > Yep, using  ASN.1 for binary format seems logical. If we agree on
> this
> >I
> >> > can share my experience of working with ASN.1.
> >>
> >>
> >> In fact, I was thinking in using your decoder, Stepan, so  that's
> great
> >> news.
> >>
> >>
> >> Thanks,
> >> > Stepan.
> >> >
> >> > 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
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Thanks,
> >> > Stepan Mishura
> >> > Intel Middleware Products 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
> >>
> >>
> >
> >---------------------------------------------------------------------
> >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
>
> ---------------------------------------------------------------------
> 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