Toward XML-dump/load-based migration

Hi,

it's been a long-term hope (of some of us at least) to support
an alternative migration path for Plone sites, namely being
able to dump configuration and content independently from
on site and load it into another. Given what we have today,
it looks like we are basically there :-)

Configuration is handled by GenericSetup now and with Plone's
(and 3rd-Party product authors) move to GS this can be considered
(almost) done. (Well, sort of at least.)

For content migration the addition and integration of 'Marshall'
in Plone 2.5 has been a big step forward and with XMLForest we
are basically there as well. (Big thanks to Sidnei, Kapil, Gogo,
and everybody else involved.)

While playing with content migration a bit recently, I stumbled
over the following two problems:

1. XMFForest can only handle AT-based content. While this is
almost always the case today, there is one noticable exception:
The PloneSite (root) itself. Specifying the site root as root
folder for an export fails when trying to access it's UID.
Now, what would it take to adapt a PloneSite to support the
interfaces necessary? (that would be which ones?) Not much,
I hope, as we "only" have to deal with it being a (or the top
level) container.

2. XMLForest uses Marshall's ATXMLMarshaller which in turn
serializes each content item by iterating over its schema
(plus some other stuff).
So far so good. For default field types this works fine but
I have trouble with some of my custom field types (those who
manage data that itself has some non-trivial structure, e.g.,
the RecordField, RecordsField, FormattableNamesField,
RemoteTextField, ...).
Looking into this more closely, it turns out that the marshaller
just uses the field's default (edit)accessor to get at the value
and the mutator to write the data back and all further (potentially
data type dependend) processing is done in the marshaller itself.
Now my question: wouldn't it be better to let the field itself
control the (de)serialization of its value? At least optionally?
How about makeing at least this part benefit from the CA, i.e.,
providing adapters from IField to IXMLFieldValue or some such
wich could be configured and further specified on field type.

Is this the right direction to go?
Anything I missed or should know?
How does member data handling fit in this picture?
(in particular when using CMFMember?)
Anyone else thinking along those lines?

Feedback welcome,

	Raphael





-------------------------------------------------------
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