[Zope] ZCVSFolder + plain text export format

[Chris McDonough]

Hi Marius,

You may want to take a look at this proposal:

http://dev.zope.org/Wikis/DevSite/Proposals/RepresentingObjectsOnTheFilesystem

Any progress on it has been prevented due to for lack of resources,
unfortunately.

On Fri, 2002-05-24 at 12:38, Marius Gedminas wrote:
> Hi,
> 
> We use ZCVSFolder here at www.CodeWorks.lt extensively, and we've been
> contributing patches to it.  One of the main chores with ZCVSFolder is
> the unreadability of XML-exported files (random object IDs, random
> reorderings of document nodes, escape sequences in document bodies
> etc.).  This makes the XMLs basically unreadable, undiffable and
> unmergeable.
> 
> As an alternative we developed an alternative export format, which
> resembles RFC-822 a lot.  Here's an example of an exported Python
> script:
> 
>   Bindings: container='container'
>           context='context'
>           namespace=''
>           script='script'
>           subpath='traverse_subpath'
>   Id: language_buttons
>   Local-Roles: mg=('Owner',)
>   Meta-Type: Script (Python)
>   Owner: acl_users
>           mg
>   Parameters:
>   Permissions:
>   Proxy-Roles:
>   Title:
> 
>   # Example code:
> 
>   # Import a standard function, and get the HTML request and response objects.
>   from Products.PythonScripts.standard import html_quote
>   request = container.REQUEST
>   RESPONSE =  request.RESPONSE
> 
>   # Return a string identifying this script.
>   print "This is the", script.meta_type, '"%s"' % script.getId(),
>   if script.title:
>       print "(%s)" % html_quote(script.title),
>   print "out", container.absolute_url()
>   return printed
> 
> Advantages:
> - This format is compact, easily readable, diffable and mergeable
> - It contains only relevant object attributes, instead of being a dump
>   of internal representation (e.g. storing both source code and
>   base64-encoded compiled bytecode for Python scripts in exported XML
>   files)
> 
> Disadvantages:
> - Export of different object types is no longer automatic, you have to
>   write code for every supported meta-type (only about 20 lines of
>   Python for every supported meta-type on average).
> - The code may drift, e.g., when new attributes are added into Zope
>   objects but import/export is not updated.  This may cause
>   maintainability problems.
> 
> I am now starting to think about future possibilities.  If such a
> representation would get officially endorsed and included into Zope
> proper, and import/export routines were added to the objects themselves,
> it would eliminate the second disadvantage (code drift).  There would
> also be a standard interface to get to a plaintext representation of
> both data and metadata, more extensive than document_src().
> 
> The possibilities are endless.  It would be nice to be able to connect
> to a running zope instance via FTP/whatever and get and edit objects in
> this format.  This would allow the users to see/change metadata also.
> There would no longer be a need for PUT_factory external methods for
> creating new objects of various kinds.
> 
> What do you think about this?
> 
> BTW if anyone wants to see the actual code, take a look into ZCVSFolder
> CVS repository (cvs.zcvsfolder.sourceforge.net module zcvsfolder),
> mg-patches branch.  It will be merged into main branch in a week if
> Steve Spicklemire approves.  I suppose I could make the code available
> on the web somewhere if there's any interest.
> 
> Marius Gedminas
> -- 
> If C gives you enough rope to hang yourself, C++ gives you enough rope
> to bind and gag your neighborhood, rig the sails on a small ship, and
> still have enough rope left over to hang yourself from the yardarm.
> 
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists - 
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )