Re: Object serialization

Date view Thread view Subject view Author view

From: Tim Wilkinson (tim@transvirtual.com)
Date: Mon Jan 25 1999 - 21:33:52 EST


Godmar,

> >
> > Godmar,
> >
> > Well the new methods would be public so Sun could complain about that (after
> > all there are no readObject methods which take an option string identifier).
>
> I see.
>
> >
> > More to the point though, does being able to serialize in XML seems like a
> > good idea? Also, does allowing the use of a simple tag in the serialization
> > operation seems a good way to do this, and could it be useful for other
> > things?
> >
>
> I don't really know.
> However, what's Sun's idea of allowing for alternate forms of serialization?

Don't think they have one do they? I've not looked at CORBA compatibility which
might have something on this.

>
>
> For instance, what if you simply subclassed ObjectOutputStream and provided
> a different writeFloat, for instance? It's not final, is it?

Probably not - but I wanted to provide XML serialization as an implementation of
serialization like SocketImpl provides the implementation to Socket - the reason
for this is that you want to be able to be able to create a ObjectOutputStream as
before. This also means that our serialization forms would need to use the extra
tag to be useful, and that's non-standard. Hmm, I'm not making myself clear
here...

>
>
> In that case, you would either code like:
>
> private void writeObject(ObjectOutputStream s) throws IOException {
> if (s instanceof XMLOutputStream) {
> ((XMLOutputStream)s).writeFloat("LOADFACTOR", loadFactor);
> } else {
> s.writeFloat(loadFactor);
> }
> ...
> }

I don't like this much because I'm not trying to tie this to XML only - I want to
be able to use different serialization protocols and I though that the tag would
be useful in XML but possibly in other too - the above just helps us out in one
case and isn't terrible extensible.

>
>
> or like
>
> private void writeObject(ObjectOutputStream s) throws IOException {
> s.writeXMLTag("LOADFACTOR");
> s.writeFloat(loadFactor);
> }

Again, XML specific - but at least it could just be "writeTag" I suppose -
doesn't change ObjectOutputStream much but it does slow serialization down by
requiring twice as many calls.

>
>
> where "writeXMLTag" has an empty implementation by default.
> Or like
>
> private void writeObject(ObjectOutputStream s) throws IOException {
> if (s instanceof XMLOutputStream) {
> ((XMLOutputStream)s).writeXMLTag("LOADFACTOR");
> }
> s.writeFloat(loadFactor);
> }
>
> I wouldn't have an immediate use for XML serialization, but I also cannot
> exclude possible uses... You will of course need an XML parser to read
> those objects in.

Sure - that's seems okay to me.

>
>
> It's also not clear to me what would be written: would it be like
> <LOADFACTOR VALUE="0.75"></LOADFACTOR>
>
> or more like
> <HASHTABLE LOADFACTOR="0.75" ...> ... </HASHTABLE>
>
> (I don't really know XML, so I am making this up.)

I'm not completely clear on the format either - I'm going to do a little reading
around - but it does seem to me that XML is simply a textual representation of an
object. And each XML 'object' is of some class or other depending on the CSS
template. There's a certain symetry to it all.

>
>
> On the other hand, doing this as part of the serialization may be bound
> to complicate things... and serialization is hard enough to get right.
> So maybe it would be a good idea to first get plain serialization working
> so that we can start fixing up classes to use the proper serial forms, and
> then look at more fancy things.

Oh I doubt it - the idea would be to seperate off the implementation of
serialization from the interface. I'm not about to launch into an XML I/O system
right now, but I don't want to exclude it by writing all those
readObject/writeObject methods and the having to go back and add lots of tags.

Cheers
Tim

--
  Tim Wilkinson                         Tel:     +1 510 704 1660
  Transvirtual Technologies, Inc.,      Fax:     +1 510 704 1893
  Berkeley, CA, USA.                    Email:   tim@transvirtual.com


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:48 EDT