Stef, Sounds great. ReferenceStream has some real problems, and it might be very difficult to change in ways that would not orphan existing data, if in fact there is any - projects perhaps?? It might be best to adopt an existing serializer or build a clean one of our own. With some care and a few compatibility methods, we can probably write tests that can work with multiple serializers, and perhaps even profile them at the same time.
Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stéphane Ducasse Sent: Tuesday, September 15, 2009 3:18 PM To: [email protected] Subject: Re: [Pharo-project] Object serialization in Pharo > Stef, > > Henry's warning tells me I'm not alone in being afraid of Squeak's > serializer. A while ago, I had settled on SIXX as the likely best > option for me, but will certainly consider other options. For the > Dolphin filer, my tests mostly center on loading objects with old > schemas. It was fairly easy to do because I had old data in > abundance, and simply loaded some of it into new images. For Pharo, > we might write tests that compile a class, serialize, make some > changes to the class and reload the "old" data. The details will > probably depend on the serializer(s) we select. > > My plan has been to start out using SIXX for network transport of data > between like images (where schema changes are not a concern) and then > begin to look at archival uses if that goes well. > > Does that answer your question? ok we will evaluate SIXX. Now my point is that we should have good solutions: so if referenceStream can be fix we fix it else we trash it. Half-baked solutions just hinder progress. My goal is this community is to set the cap (fun for a lighthouse) and the cap for 1.2 and other releases. I want a neat nice robust working documented system and each step going in that direction is an important one. Stef > > Bill > > > -----Original Message----- > From: [email protected] > [mailto:[email protected] > ] On Behalf Of Stéphane Ducasse > Sent: Tuesday, September 15, 2009 1:19 PM > To: [email protected] > Subject: Re: [Pharo-project] Object serialization in Pharo > >> Stef, >> >> The packaging constraint had nothing to do with Pharo. See the [ANN] >> thread on #readStream replacing ReadStream on: (around 4 Sept). >> SecureSqueak is the system with the apparent limitation; it really >> does have that constraint, it will not be of much use to me. >> >> Unit tests for a serializer would be well-taken, but I will largely >> have to start over. Choosing a filer seems to be the first step. >> Squeak's ReferenceStream did not strike me as a good option; if you >> wish to argue in its favor, please do so. Otherwise, I would like to >> see SIXX get a good evaluation, as well as any other options that >> should be considered. > > I'm sure that I want an XML parser in the way but why not. > I started to write some tests just to learn and document. I would even > have no problem to throw away everything it there is a better > solution. Now what tests will let enable us to change and nothing what > we change. > > Stef >> >> Bill >> >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected] >> ] On Behalf Of Stéphane Ducasse >> Sent: Tuesday, September 15, 2009 10:06 AM >> To: [email protected] >> Subject: Re: [Pharo-project] Object serialization in Pharo >> >> >> On Sep 15, 2009, at 4:16 PM, Schwab,Wilhelm K wrote: >> >>> Simon, >>> >>> I wish you well and will be eager to hear progress reports. Long >>> ago, I looked at ReferenceStream (or maybe SmartReferenceStream), >>> and did not like what I found. IIRC, the output for simple examples >>> was much larger (of course, it might not continue to scale so >>> unfavorably) compared that that produced by Dolphin's binary filer. >>> Another concern was schema changes. >>> >>> Dolphin has an orderly conversion process that will raise an error >>> if it is not prepared for what it finds; Squeak seemed to want to >>> fix it itself with the aid of the user (not gonna fly in an end-user >>> app or a server process, which is pretty much everything). >>> >>> Dolphin locates conversion methods in the class of the object being >>> converted or in the class of a proxy for it (that sounded scary to >>> me when I read about it, but it is exactly what one would want in >>> practice). In contrast, Squeak puts the conversion methods in >>> ReferenceStream. Yuk!!! Sorry, don't know what just came over me >>> :) Of course one can always modify ReferenceStream[*], but imagine >>> the chaos if ReferenceStream were to become widely used. >>> >>> I have used serializers to good effect and would like to continue >>> doing so. At the moment, I would look again, but would lean away >>> from ReferenceStream. >> >> I started to write some tests in the PharoTaskForces. >> If people want to join effort because before changing I would like to >> know what is there. >> >>> SIXX (an XML serializer) is a possibility. As I recall, its output >>> was not terse (but might compress nicely??). There originally was >>> minimal to no support for shape changes, but that has been >>> addressed; I cannot speak for how well it has been done because I >>> have not had time to look. It is on my todo list and might float to >>> the surface soon, though initially I would not need to care about >>> shape changes. >>> >>> HTH >>> >>> Bill >>> >>> >>> [*] I think we recently discussed a Squeak fork that would not allow >>> touching base classes due to packaging limitations. >> >> really? >> >>> Not good. I am not defending the ReferenceStream example, but it >>> would be a big problem on that system, if I understood that thread. >> >> I would like to fix that >> We need a good object serializer. >> >> >>> >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected] >>> ] On Behalf Of Simon Denier >>> Sent: Tuesday, September 15, 2009 8:32 AM >>> To: Pharo Development >>> Subject: [Pharo-project] Object serialization in Pharo >>> >>> Hi folks >>> >>> I'm looking at the code and comments of ReferenceStream for object >>> serialization and I wonder what is the best strategy to serialize a >>> partial model. I mean, I want to store all elements found while >>> traversing the graph of the model, but I dont want to store some >>> attributes of those elements (i.e., transient attributes). >>> >>> Any sample? >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
