harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivanov, Alexey A" <alexey.a.iva...@intel.com>
Subject RE: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
Date Thu, 03 Aug 2006 10:01:13 GMT
Miguel,

Does it make sense using ASN.1 then, if it's complex and not pretty?
OTOH formal description is an advantage.

I believe we can write the data needed with just DataOutputStream
methods, but it might not be clear.

We can improve serialization so that it works fine and in
JVM-independent way by overriding readObject/writeObject methods in the
classes to be serialized. (The classes under consideration are from
html.parser package, I believe so.) 

Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division


>-----Original Message-----
>From: Miguel Montes [mailto:miguel.montes@gmail.com]
>Sent: Wednesday, August 02, 2006 8:40 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][html] Should we try to be binary compatible
with
>Sun's bdtd?
>
>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

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


Mime
View raw message