Dolphin Registry Serialisation package

Hi,

I just discovered the Dolphin Registry Serialisation package and it
looks very handy! I had seen some of the methods, but just assumed they
were putting/getting STB byteArrays into the registry. Not so! ... it
is a new serialization framework.

Does anyone have any experiences with it to share?

Some initial thoughts and a few things for the wish list:

 - Without actually testing, it doesn't appear to handle object pointer
cycles. This is fine with me, except it would be nice if it detected a
cycle and signaled an error. I have just read on msdn that a registry
tree is limited to 512 levels ... so I guess that would stop a cycle
relatively quickly ... but leave a mess.

 - It is handy that it is more resilient to shape changes than STB. If
the class has extra instance variables added, old serialized instances
can still be read. However, if the class has instance variables
removed, an error is signaled.

Personally I would prefer it to not signal an error in this situation,
so that it is even more resilient to shape changes. I feel that any
object that is deserialized from the registry needs to be checked for
validity anyway (treated as user input). So, I would prefer the package
to read as much information as possible, and then let me decide if it
is valid or not, and fix it up if needed.

If my argument does not convince, a compromise solution might be to
make errors during deserialization resumable (Specifically I am looking
at the send of #at: in ClassDescription>>readFromRegKey:)

 - I am wondering if the storing of objects could be made more robust.
Object>>storeUnderRegKey:as: removes any old serialized object and then
stores the new object. If the store is interrupted at that point, you
lose the old and the new instance. Instead of removing the old key,
could it just overwrite the values?

If this change is made, my preference would be to leave any (named)
values that are not named instance variables of the current object's
class being serialized (but remove any extra indexed instance
variable).

This would allow older versions of an object to be
deserialized/serialized without overwriting data from a newer version
of the object. Of course this does not guarantee consistency when
deserializing, but I am assuming that any object serialized into the
registry can (and no doubt will) be changed by a user at some point,
and therefore needs to be fully validated by my code when deserialized.

Bottom line is, as mentioned above, I have only just discovered this
package, so my wishes may be off target. However, I feel that if I want
to store an object with guaranteed consistency, I will use STB (and
even digitally sign it). I think where I would use the Dolphin Registry
Serialisation package is to easily store user settings, where I want
shape changes to be handled on a best effort basis.

Steve

Hi Steve,

 I don't explore *yet* that mechanish, but I use a customized
serialization based on OmniBase serializer wich is known to be very
nice (efficient, robust, flexible).

  It could be a nice choice, specially now that OmniBase is a close
friend of the dolphin.

 In some cases I serialize, in this way, objects that I store in the
registry with the normal RegKey #at:put: method.

  I remember that I've used a nodified transaction for that. If you
want more info about that, just ask.

  Regards,

Sebastian

OmniBase offers very simple yet powerful serialization. For the simple
case you can use just:

ODBSerializer serializeToBytes: anObject

And for deserialization just use:

ODBDeserializer deserializeFromBytes: aByteArray

With additional parameters you can even store class definitions
externaly or declare some objects as external to the serialized object.
All these features are used in OmniBase for storing persistent objects.

OmniBase serialization is dialect independent and will handle class
schema changes.

Best regards,

David Gorisek



Sebastián wrote:

Hi Sebastián and David,

Thanks for the tip on using the OmniBase serializer. I had not
considered using it outside of Omnibase, but it looks very
comprehensive. I will look into it.

Thanks!
Steve

"Steve Alan Waring" <[hidden email]> wrote in message
news:[hidden email]...
> Hi,
>
> I just discovered the Dolphin Registry Serialisation package and it
> looks very handy! I had seen some of the methods, but just assumed they
> were putting/getting STB byteArrays into the registry. Not so! ... it
> is a new serialization framework.
>

Steve, the package is only really designed for storing simple application
settings (as you later suggest). Although this can be done using binary
serialisation, this means the settings are opaque and can't be
viewed/changed in RegEdit. As I'm sure you spotted the XmlPad sample stores
the text-style settings in the registry using the package.

Frankly I think the design could be better (as the designer, I'm happy to
slag it off). As is often the case there is an object (class) missing. It
really needs a serialisation context passed around which could then have
different implementations which could handle circularities, etc. I hadn't
really intended that it be shipped in D6, but because it was used in a
sample we wanted to include, it got left in. It's fit for its limited
purpose though.

> Does anyone have any experiences with it to share?

It has been used in one commercial application that we developed, just for
storing app settings. In fact that was why it was written.

>
> Some initial thoughts and a few things for the wish list:
>
> - Without actually testing, it doesn't appear to handle object pointer
> cycles. This is fine with me, except it would be nice if it detected a
> cycle and signaled an error. I have just read on msdn that a registry
> tree is limited to 512 levels ... so I guess that would stop a cycle
> relatively quickly ... but leave a mess.

It's not really intended to handle that situation. As I say, the design
would probably have to be modified to accomodate this efficiently.

>
> - It is handy that it is more resilient to shape changes than STB. If
> the class has extra instance variables added, old serialized instances
> can still be read. However, if the class has instance variables
> removed, an error is signaled.
>
> Personally I would prefer it to not signal an error in this situation,
> ...

I think your suggestion is a good one. Bearing in mind the intended usage, I
don't see any particular benefit to "extra" data being an error.

In conjunction with the above change, that seems reasonable. Ideally though,
I think one would want to be able to choose whether or not old data is
preserved.

Thanks for the suggestions

Blair