Jim Fulton <[EMAIL PROTECTED]> wrote: >We need to either remove zope.app.fssync.file, or, if we think that >fssync is moving along well enough, we need to move >zope.app.ffile.fssync to a separate project in some namespace >package, such as zope.app.filefssync. > >fssync is too experimental to include zope.app.file.fssync in >zope.app.file.
I agree that fssync is still experimental. The DefaultFileAdapter setBody and getBody methods, for instance, do not apply well to Blobs and other file implementations. Another problem, at least for me, is that the current implementation addresses more the use case of export/import than the use case of content management. Currently FSSync replicates the ZODB object tree in the filesystem, serializes everything into a temp file, and starts to respond after these very expensive operations. How are the chances that the response.write method is reinstated in the future? Or are there already alternatives I have missed? Given that zope.app.fssync needs more work, wouldn't it be better to move everything into one place then, e.g to zope.app.fssync.file, zope.app.fssync.zptpage etc? If the API becomes stable we still can create the separate projects. Regards, Uwe _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
