From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Wed Jan 27 1999 - 04:08:38 EST
On Jan 25, 1999, Tim Wilkinson <tim@transvirtual.com> wrote:
> Then I had another thought- I should split out the actual serialization
> protocol from the serializing objects - so we get both a
> Object{Output,Input}Stream which passes on to an
> BasicObject{Output,Input}StreamImpl.
I think the best way to support this is the following:
Create an abstract class (or interface, now that they're fast :-)
named kaffe.*.ObjectSerializer, that declares all the write methods
with a tag parameter in addition to the value. Define a final
subclass kaffe.*.ObjectOutputStreamProxy, that can be constructed out
of an ObjectOutputStream, that just delegates every invocation to this
underlying ObjectOutputStream object, obviously omitting the tag.
The standard serialization API (ObjectOutputStream.writeObject) would
try to use writeObject(ObjectOutputStream). If this method does not
exist, it would try writeObject(ObjectSerializer) with a temporary
proxy. If no such methods exist, standard serialization occurs, using
either the ObjectOutputStream or the ObjectSerializer.
Other subclasses of ObjectSerializer, such as the one for XML, would
probably try writeObject(ObjectSerializer) first, and either fail or
enter opaque mode if they have to revert to ObjectOutputStream, using
a subclass that forwards writeObject invocations back to the
ObjectSerializer.
ObjectInputStream would be handled symmetrically.
Can you make any sense out of this?
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:50 EDT