On Fri, Feb 25, 2011 at 2:22 PM, Emmanuel Lecharny <[email protected]> wrote: > Hi guys, > > I'm reworking all the serializations for the base objects we are > manipulating. I have a few questions and I'd like to get you opinion. > > The base idea is to get rid of all the Externalizable/Serializable > interfaces, and to provide our own helper classes to serialize the objects > we have to write down the disk. The rationnal is that we avoid the cost of > writing the useless java class informations, keeping the written objects as > small as possible, and the process as fast as possible.
Could you provide some of the problems that you encountered due to the use of the Externalizable/Serializable intefaces in some of these classes? > Q1 : Do we have to store a version number into the written data ? +1 > Q2 : I'm going to inject the SchemaManager in all the deserialized data (it > can be null, if the SchemaManager has not been created). Do you think it's a > problem ? We can have separate serialization services that have a handle on the SchemaManager. These services can use schema information to handle their task of [de]serializing. However there are some entities that need access to schema information in order to conduct some operations like Entry.add( attribute ). How we handle access to schema information while they perform schema checks is another matter which we need to discuss. Perhaps a schema aware Entry wrapper can access this information leaving the simple Entry free to do as it likes while it intercepts calls and conducts schema live checks before delegating the call. Things like this can also be handled automatically with byte code manipulation. We can discuss this separately which would be involved. > Q3 : In order to be able to create the object as it was when it was > serialized, I'll create package visible only constructors, with all the > needed parameters. Does it sounds the right approach ? This will require the [de]-serializer to be in the same package. That could present an issue with split packages if we want to make these entities into services down the line. I'd go ahead and make the constructors public for now. Off the top of my head I cannot think of a detriment to exposing these constructors but perhaps you have some in mind? Regards, Alex
