[Zope3-dev] future of fssync (was: RE: [SpringCleaning07])

[Uwe Oestermeier]

Sorry for replying so late. I have just checked in some bug fixes for
fssync (r72206).
This was indeed not much work.

Jim Fulton <jim at zope.com> wrote:
>I don't think a whole lot is needed to make fssync a reality:
>
>1. Cure any bitrot that has set in.  It would also ne nice to replace  
>existing
 
>tests with modern doctests.
>
>2. Provide a Python API. fssync originally had a Python API, but this  
>was
>     replaced with a web-based API.  I think there should be both a  
>Python
>     API that wasn't encumbered in any way by security, and a  
>protected web-based
>     API.  The Python API should really be Zope and even ZODB  
>independent.
>     I don't think this would be a lot of work.  The original one  
>wasn't and would
>     be useful in many cases.
>
>3. I think there should be a secure web-based interface.  This will  
>require:
>
>     - Adding security checks that the user is allowed to access  
>serialization
>       and de-serialization adapters,
>
>     - Adding security declarations for these adapters,
>
>I don't think any of these would require a great deal of work.

I can try to deal with these tasks, but I fear that there is a little bit
more to do.
While playing with real data, I noticed

	- problems  to serialize large sites (I run into a stack overflow and
have still
	   to figure out why this happened),

	- problems with unicode filenames.

As a first step I would like to clean up the existing code. Concerning
this I have questions/suggestions:

	- Can the fssync:adapter zcml directive be replaced  by ordinary trusted
adapters?

	- Can zope.app.fssync.fspickle be replaced by zope.xmlpickle? (It seems
that fspickle preserves location ids but it does not seem to preserve the
order of dict items)

	- What's the purpose of zope.app.fssync.fsbundle? Are there still
usecases for this code or can it be removed?

	- What's the purpose of zope.app.fssync.fsregistry? Can this be replaced
by utility registrations?

All in all the fssync code seem to be in an old-fashioned but usable shape
and it's  a pity that it has not been maintained.
Perhaps the maintenance can be made easier if we can change the code
without deprecation warnings. Nobody seems to have used fssync in the last
two years.

Regards,
Uwe


________________________________________________________________
Dr. Uwe Oestermeier
Institut für Wissensmedien
Knowledge Media Research Center
Konrad-Adenauer-Str. 40
D-72072 Tuebingen
Germany
u.oestermeier at iwm-kmrc.de
Tel. +49 7071 979-208
Fax +49 7071 979-100