Re: Toward XML-dump/load-based migration

Martin Aspeli <optilude@...> writes:

[..]

> I think this is a sorely needed feature that's been "almost there" for a  
> long time. If you have some bandwidth to put into it, that'd be great. :)

Well, as I need this myself, it looks like I'm already right
into it ;-)

[..]

> I am still a bit confused about the interdepencies of the stack  
> GenericSetup/xmlio/Marshall/XMLForest, but hopefully this will become  
> clear.

That's not that hard actually:
1. site configuration is handled by GenericSetup.
2. AT marshalling is about content object serialization.
   While AT supports marshalling from the very onset in 
   principle, the marshallers provided so far were not 
   "loss-less", so they could not be used for migration
   (at least not without serious extensions).
3. Kapil's and Sidnei's Marshall product adds further (XML-based
   - but that's not really the point here) more powerful
   marshallers that can handle any AT-based object and dump more details.
   What we sometimes refer to as "xmlio" are the XML
   marshallers from the "Marshall" product (there are actually 2).
4. XMLForest adds arbitrary relation handling including containment
   so you can handle complete (content) trees including references.

[..]
> 
> Basically, the only sensible way of doing this would be with Zope 3  
> interfaces and adapters.

Guess why I use terms like "adapt" and "which interfaces"
in my original posting ;-)

> We would need to be able to adapt any content  
> object to a serialiser-deserialiser, at the very least, and possibly offer  
> finer grained interfaces in the AT implementation for field-level  
> serialisation-deserialisation. 

Right.

> I don't imagine separating concerns like  
> this would be terribly hard, and it would probably make the code a lot  
> easier to test and develop.
> 
> I can't think of any particular problems with CMFMember (heck, it's just  
> content after all), but then again :)

Yeah, well, that's kind of the point. CMFMember handles member
data like content while CMF/Plone's default memberdata tool doesn't.
Maybe its a non-issue as long as you don't change this on migration.
All in all I think we'll need to have some additional means for
user migration anyway (at least for those not using an external user
source). This would probably be the right place for any member data
handling anyway.

Raphael

> 
> Martin
> 






-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642