A look at my Data API proposal from Drupalcon Brussels 06

All this import/export malarky is actually part of a problem I identified many years ago, while writing FAPI.

FAPI in it's current state was always meant to be the first phase in a much larger project to fix a lot of the inherent design problems we have been bumping heads against now.

If the code looks 'non-drupal like' to you, keep in mind when this presentation was done, FAPI itself was new, and such sweeping changes still had an opportunity of being taken seriously. Unfortunately I suffered from burnout shortly afterwards, and extracted myself from doing serious core development.

FAPI3 - AKA Data API presentation

Read below for some comments on this :

What you should take away from this is in the short term :
a) you need a mechanism to define the data model, separate from just adding a field to the form
b) your crud actions need to operate on this data model ( not on the form submission )
c) you need to be able to extend the data model through AOP, so you can get a structure containing what the site thinks the object should look like.

In the long term, forms api integration would mean :
a) the data model can be used as 'scaffolding' to generate a base form, which reduces the amount of code necessary.
b) the form is just a type of 'display' of the data model, reducing the difference between view and display.
c) the form needs to populate it's values through lazy evaluation and introspection, you can't just use "value = $object->value".
d) relationship API is going to be one tricky motherfscker, we will need a rock solid mechanism to detect the id fields of the object.

There's more, and I'll answer questions related to this, but people need to keep in mind that we are playing a 'long game' with some short term goals to get us up and running.