==========================================================
Things to do for the next release (in no particular order)
==========================================================

Notes from Uwe Oestermeier on improving efficiency
--------------------------------------------------

the problem arises if a site contains large blobs.

If I remember the implementation correctly, all objects are serialized
completely into a temporary SNARF archive and streamed afterwards.  It
would be more efficient if the SNARF could be streamed directly to the
response. This was possible in the first version of zope.fssync.

As far as I know direct streaming to the reponse is no longer
supported in Zope3. (Jim Fulton indicates that this isn't true.)

Another optimization would be if client and server could communicate
about the necessary parts that need to be exchanged.  In ordinary
circumstances, for instance, it is unnecessary that all items are
serialized by a zsync update.  Checksums would be helpful here. They
are easy to compute on write operations and could be used to compare
the server and client state before the real data transfer
starts. SNARFs which contain checksums instead of content data can
also easily be cached on the server.

These optimizations are of minor importance if one uses zsync mainly
to move data from one machine to another.  For a user who want's to
edit a few documents offline these improvements are much more
relevant.



Miscellaneous
-------------

- Remove dependency on zope.traversing which presupposes zope.app packages

- Add a callback for synchronization handlers which allows to
  update caches, catalogs, etc.

  synchronizer's load method may now return a callback (which in turn
  can return a callback, etc.) So this may resolve this item.

Bug Fixes
---------

