Jim Fulton <[EMAIL PROTECTED]> on Mittwoch, 24. Januar 2007 at 16:48 Uhr +0100
>Maybe, but I like your idea of using utilities below. My original
>along these lines: fssync should strive to serialize "all" object
>data. (Note that it isn't always obvious what data is intrinsic to
>an object.) I felt therefore, that inheriting synchronization
>adapters would be bad. If someone created a subclass and forgot to
>create an adapter, then their data would be serialized incompletely.
>I like the idea of using named utilities, using dotted class names as
>utility ids. See below.
Ok, I will give named utilities a try.
>> - Can zope.app.fssync.fspickle be replaced by zope.xmlpickle? (It
>> that fspickle preserves location ids but it does not seem to
>> preserve the
>> order of dict items)
>I'm a bit rusty on this. I would think that these can be combined.
>It should, I think, be possible to generate location-aware pickles
>and then use zmlpickle to represent these as XML. The trick, I
>think, would be use the pickle persistent-reference mechanism to
>refer to other objects by location, when necessary. I say this
>without looking at the code. :) If you need me to dig deeper, I'll
>try to find time to do so.
I found such a combination in zope.fssync.server.entryadapter. There a
location-aware pickle was created by fspickle.dumps and converted via
xmlpickle.toxml. This version generated xmlpickles with changing dict
representations which in turn led to false alarms that objects had been
I will try to combine the xmlpickle._PicklerThatSortsDictItems with the
fspickle.ParentPersistentIdGenerator and see whether this solves the
problem. If this doesn't work, I will ask you for further assistance.
Dr. Uwe Oestermeier
Institut für Wissensmedien
Knowledge Media Research Center
Tel. +49 7071 979-208
Fax +49 7071 979-100
Zope3-dev mailing list