Hi Folks,

I posted this to the Wiki... but it's not "in-your-face" like email,
so I never know if anyone reads it. Here are a few, possibly random,
but nonetheless concrete, thoughts of mine on the matter. I'm looking
at all this from the perspective of someone who is using the current
xml/zexp code to manage objects in CVS today, and hoping that whatever
evolutionary/revolutionary process that occurs here not completely
break all my existing stuff. It seems to me that the current import/export
mechanism is actually pretty close to what we need for serialization. It
has some nice  properties:

A) All objects are faithfully encoded and saved on the filesystem
  in a text format that any configuration management system can
  use and track. It seems to me that this property is critical
  to maintain.

B) Whole object hierarchies can be saved in a simple file, moved
  to any other zope instance (via checkin/checkout) and instantiated.
  (This is needed for import/export to be useful)

C) It's possible (through a hack[1]) to make simple objects 'diff'able
  so that all the metadata that's in the current xml export rep doesn't
  get in the way too much. (this is almost irrelavent, but may be
  useful as an interem step to make this part of the native import/export
  code... )

There are also a few not-so-nice properties:

D) The current xml representation use by xml import/export is morally
  binary, in the sense that you can't easily edit/manage it with
  ordinary editors etc.

E) There is no simple way to separate the contents of a containerish
  object from the container. 

I think that both of these shortcomings could be addresses using Chris M's
idea of letting objects handle their own serialization. (e.g., Folders
could save their meta-data in a 'special' file, or directory and then
proceed to call the serialization methods of their contents). However
I think there would be benefits to working this into the current
import/export scheme. Imagine the following:

A 'serialization' interface is invented that objects could implement
that preserve A-C, and, optionally, fix D-E. If no such interface
is found, the current export method is invoked. (I suppose this could
also be done by adding a default implementation of the interface
that simply does what the current import/export code does.) 

Something like this maybe?

class FSObject:

      """ Abstract filesystem Object that 'does the right thing'. 
          Might be implemented as StringIO, or impose special
          security restrictions, or whatever. 
      """

      def chdir(.. )

      def mkdir(.. )

      def open(.. )

class Serializable:

      Serialize(self, serialize_contents_separately=None, use_fs_object=None):

      """ Serialize this object. If serialize_contents_separately is
          not None then create a 'special' file for meta_data, and
          create a new directory for self and subobjects. After saving
          meta_data, call Serialize on each content object in turn,
          passing appropriate arguments through.. """


Anyway.. it seems to me that this sort of approach would have the
benefit of using what's available today to the best advantage while
permitting tools to be developed that would work well with whavever
serialization process that evolves for all the Zope objects that
are out there.. 

take care,
-steve

[1] See the ZCVMixin product: ZCVSExIm.py 

>>>>> "CM" == Chris McDonough <[EMAIL PROTECTED]> writes:

    CM> I think the only good reasons we have right now for having
    CM> filesystem-compatible serialization are to make Zope content
    CM> editable via common tools in a way that makes sense to people
    CM> not used to (or comfortable with) the object database, and to
    CM> give people a plausible way to put a Zope site under source
    CM> control.

    CM> Are you thinking that we would build client-side tools to
    CM> recognize an XML representation of a subpart of a site?


    CM> ----- Original Message ----- From: "Karl Anderson"
    CM> <[EMAIL PROTECTED]> To: "Chris McDonough"
    CM> <[EMAIL PROTECTED]> Cc: "John D. Heintz"
    CM> <[EMAIL PROTECTED]>; "Fred Wilson Horch"
    CM> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday,
    CM> March 22, 2001 8:17 PM Subject: Re: [Zope-dev] FTP interface
    CM> being worked on?


    >> "Chris McDonough" <[EMAIL PROTECTED]> writes:
    >> 
    >> > I don't think it's reasonable or wise to impose any "master >
    >> structure" for filesystem serialization of bodies of > objects.
    >> Each instance (or perhaps each class) should > define how best
    >> to serialize itself to disk.  > Representations between classes
    >> are likely to be radically > different.  A place for
    >> standardization is in the > "properties" file(s) which
    >> accompany each object rep... this > is likely to be XML or
    >> another structured variant.
    >> 
    >> Is there a motivation for using serialization to provide an
    >> editable "god's eye view" of all or part of a Zope site?
    >> 
    >> That is, provide a two-way XML serialization at any stage of
    >> the managed hierarchy of a site?  That way, XML tools could be
    >> used as stream editors at any level, to the extent that the
    >> serialization is understandable.
    >> 
    >> So, for example, we'd have ways to not just alter a template or
    >> content that gets templatized, but the containers that organize
    >> them, and related metadata or content that isn't as near.
    >> 
    >> This links well with the standardization that you mention -
    >> objects can have arbitrary serialization formats, but if
    >> certain attributes that we're interested in are recognizable,
    >> those attributes could be edited on a containerwide level.  So,
    >> if we had arbitrary objects that we wanted to have an effect on
    >> content or display, the same XML tools could be used to manage
    >> them all, limited only by the ability of those tools to slog
    >> through a level of the hierarchy.
    >> 
    >> This is kind of stream-of-consciousness talk, and might be more
    >> silly than realistic; certainly, if the objects didn't guard
    >> how they could be updated, a misconfigured tool could waste
    >> them without warning.
    >> 
    >> There's a similar project called psilib that was discussed in
    >> xml.com: <http://www.xml.com/pub/a/2000/03/22/psi/index.html>
    >> 
    >> --
    >> Karl Anderson [EMAIL PROTECTED]
    >> 
    >> _______________________________________________ Zope-Dev
    >> maillist - [EMAIL PROTECTED]
    >> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross
    >> posts or HTML encoding!  ** (Related lists -
    >> http://lists.zope.org/mailman/listinfo/zope-announce
    >> http://lists.zope.org/mailman/listinfo/zope )
    >> 


    CM> _______________________________________________ Zope-Dev
    CM> maillist - [EMAIL PROTECTED]
    CM> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross
    CM> posts or HTML encoding!  ** (Related lists -
    CM> http://lists.zope.org/mailman/listinfo/zope-announce
    CM> http://lists.zope.org/mailman/listinfo/zope )


_______________________________________________
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to