I'm not sure I've followed your thought process entirely, but here's how
I see things.
Currently, there are varying levels of serialization support:
Each approach has benefits/drawbacks that have to be weighted against
the goals, requirements and restrictions of the application.
Moreover, I believe we have to take into consideration that these
approaches are meant to handle "business objects" serialization and to a
very limited extent, support the need for building higher-level data
structures, such as B+Trees and HTrees.
If we want to extend support for other data structures (e.g. BLOBs), I
think we should consider building a separate, lower-level API that would
expose the underlying "logical" file with some sort of block-oriented
operations. It would then be easier to design data-structres that take
advantage of physical block sizes, with either implicit/explicit caching.
Thompson, Bryan B. wrote:
> I've been quiet while finishing up some test cases and thinking some
> more about how to approach serialization of "compound" records. The
> drawbacks with using the Externalizable interface are: (1) it does not
> take advantage of transparent versioning of serializers -- you have
> to handle your own versioning of your externalizable format; and (2)
> it does not separate the serialization logic from the business object.
> I've been looking at how easy it would be to support a stream oriented
> serializer interface (StreamSerializer) with some methods similar to
> those on the Externalizable interface, but unlike the Externalizable
> interface (and like the Serializer interface) it is designed to be
> implemented by specific serialization classes, so it would decouple
> the business objects and their serialization and also provide for
> transparent versioning of serializers. A non-goal of StreamSerializer
> would be BLOB support. I think that streaming very large objects to
> the store deserves a separate API. The StreamSerializer would target
> complex records, such as BPage, but not very large records. The result
> of applying a StreamSerializer would be a byte and that byte would
> be handled in the normal manner by the recman.
> There are two flys in the ointment. First we would need to have a
> common interface for Serializer and StreamSerializer, though perhaps
> the StreamSerializer would only be used with the extensible serialization
> support, otherwise the new interface would wind up in the insert, update,
> and fetch methods on the recman, which would change the method signatures
> (code compatibility).
> The other issue is that this basically means implementing ObjectOutput
> and ObjectInput ourselves - either over DataOutputStream and
> DataInputStream or using the mechanisms available to subclass
> ObjectOutputStream and ObjectInputStream. I've looked into the subclass
> option a bit and it does not offer much (really anything) over just
> reimplementing ObjectOutput and ObjectInput ourselves. All of the
> really important methods are private or final and when there is a means
> to extend the class, e.g., writeObjectOverride, then the methods and
> classes that you would want to use are private.
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> Jdbm-developer mailing list
Alex Boisvert, Product Development Director
Intalio, Inc. | http://www.intalio.com