Hi All,

I'm still working on zope.fssync and zope.app.fssync. When I started, I
had the hope to finish this work before the 3.4 release, but as always it
took longer than expected. Now I'm unsure how to proceed.

I have refactored zope.fssync and zope.app.fssync into two clearly
separated packages:

- zope.fssync contains now a Python API that has no critical dependencies
on Zope, the ZODB, and the security machinery.

- zope.app.fssync contains a protected web-based API and special
synchronizers for zope.app content types.
Other major changes are

- synchronizers (i.e. serialization/de-serialization adapters) are created
by named utilities which use dotted class names as lookup keys

- added doctests for zope.fssync and functional doctests for
- support for large files
- adapters for pickler, unpickler and handling of persistent pickle ids

- binaries are no longer merged
- case-insensitive filesystems and repositories use disambiguated names on
export and the original names on import
- export and import of directly provided interfaces
- direct export to archives/direct import from archives
- addressed encoding problems on Mac OSX

I can commit these changes to the trunk before the feature freeze, but I
have mixed feelings about doing so, since there are still problems to be
solved, e.g.

- export/import of int id utilities and catalogs: both should be rebuild
and not serialized/de-serialized and in the moment it is unclear to me
whether we need a fssync-specific form of post processing for this 

- missing doctests for the use case of content management

Therefore I propose to postpone the release of zope.fssync until the next
release cycle.

Any comments?


Dr. Uwe Oestermeier
Institut für Wissensmedien
Knowledge Media Research Center
Konrad-Adenauer-Str. 40
D-72072 Tuebingen
Tel. +49 7071 979-208
Fax +49 7071 979-100

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to