D6 impoved serializer?

OA team,

    will Dolphin 6 have an improved serializing mechanism?

    I ask this because I found previous versions of dolphin's
serializers very unflexible.

    This could help when your released version of an application has
produced files of serialized objects that had been refactorized on the
actual version of the application and now you cant deserialize them
(for instance think the ones you'll make with D6 and open in D7).

   No to have a good serializer has expensive implications for an
evolutive approach to software development (several releases made in
short time, considerable ammount of refactoring, agile development
thecniques).

   To give an example I found the OmniBase serializer pretty good
(robust, flexible, etc), I wish that the standard Dolphin serializer
could be so nice.

   regards,

Sebastián

Sebastián,

>     will Dolphin 6 have an improved serializing mechanism?
>
>     I ask this because I found previous versions of dolphin's
> serializers very unflexible.

Not really. One of the original design criteria for the STB filer was
that it should be fairly fast to reconstitute objects.  This is one of
the reason that we never put in a map of the instance variable names to
index locations.  This feature, would no doubt have made the STB format
significantly more resilient to class shape changes. Whilst this change
is in our list of TODOs for Dolphin, it is not a priority item and will
not, therefore, be in an early release of D6.

There is, however, one significant addition to the serialisation
mechanism in D6; a LiteralFiler.  This basically uses the same
framework as STB (although it is called STL, for SmallTalk Literal
format) although the output stream contains only literal Smalltalk
objects rather than bytes.  We use this for filing out a view
resources, which are now held as methods rather than byte arrays.  As
an example, here is the default view resource for TextPresenter:

---

resource_Default_view
        "Answer the literal data from which the 'Default view' resource can be
reconstituted.
        DO NOT EDIT OR RECATEGORIZE THIS METHOD.

        If you wish to modify this resource evaluate:
        ViewComposer openOn: (ResourceIdentifier class: self selector:
#resource_Default_view)
        "

        ^#(#'!STL' 3 788558 10 ##(STBViewProxy)  8 ##(TextEdit)  98 16 0 0 98
2 8 1140916352 1025 416 0 524550 ##(ColorRef)  8 4278190080 0 7 0 0 0
416 0 8 4294906635 852486 ##(NullConverter)  0 0 1 983302
##(MessageSequence)  202 208 98 3 721670 ##(MessageSend)  8
#createAt:extent: 98 2 328198 ##(Point)  11 11 722 241 39 416 658 8
#selectionRange: 98 1 525062 ##(Interval)  3 1 3 416 658 8
#isTextModified: 98 1 32 416 983302 ##(WINDOWPLACEMENT)  8 #[44 0 0 0 0
0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255
255 255 5 0 0 0 5 0 0 0 125 0 0 0 24 0 0 0] 98 0 722 193 193 0 27 )

---

The advantages of holding view resources as method definitions such as
this are several.  For example, refactoring of class names will now
take into account the classes referenced in resources and browsing
references to a symbol will also be able to find menu command symbols
too. The deployment mechanism has also been significantly simplified by
avoiding the need to "look inside" resource definitions for symbols and
class names.

So, I suppose you can say that there have been some advances in the
serialisation mechanism in D6 but I suspect they are not the ones you
are looking for.

> To give an example I found the OmniBase serializer pretty good
> (robust, flexible, etc), I wish that the standard Dolphin serializer
> could be so nice.

One should also realise that STB was never intended to be a replacement
for any form of object database. Omnibase is a good solution, so why
not use it?

best regards,


--
Andy Bower
Dolphin Support
www.object-arts.com

Thank you Andy, I'm already using OmniBase and I'll see if it's
serializer fits to my needs not for object database, but serialized
object ones.

regards,

Seb

Sebastian,

you can use OmniBase serializer without the database. For instance to
serialize an object to bytes just use:

ODBSerializer serializeToBytes: anObject

to deserialize use:

ODBDeserializer deserializeFromBytes: aByteArray

The serialization format is very compact and dialect independent. You
can also specify which objects should be left out etc. See the code for
details.

Best regards,

David Gorisek
http://www.gorisek.com

Sebastián wrote:
> Thank you Andy, I'm already using OmniBase and I'll see if it's
> serializer fits to my needs not for object database, but serialized
> object ones.
>
> regards,
>
> Seb
>

Wouldn't it an interesting idea, if Object Arts licensed the Omnibase
Serialzer to make it the standard serializer.

Advantages:

* I suspect that the Omibase serializer already solved problem to make the
stream independet of class shape changes.
* Dolphin serialized objects could be loaded into other dialects.
* Less developemnt costs for both sides and more standardization in the
Smalltalk comunity.

I think the latter (standardization) is one of the problems for Smalltalk in
business. Every implementation has its own proprietary serializer, gui
framework and so on, which leads managers to move away from Smalltalk,
because of the lacking standardization.

Any comments?

Regards

Carsten

"David Gorisek" <[hidden email]> schrieb im Newsbeitrag
news:42d91041$[hidden email]...

Thank you David, I'll take a look at it.

best regards,

Seb