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
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:48 EDT