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]... > 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 > > |
In reply to this post by David Gorisek-5
Thank you David, I'll take a look at it.
best regards, Seb |
Free forum by Nabble | Edit this page |