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  

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.


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

Reply via email to