The port module does a subset of what the deployment framework does. The notion of 'symmetry' of export and import functions is very powerful and can be used for not only deployment - and this actually brings me to my point: I'd like to suggest to break out this functionality of deploy module.
With port.module I came from a different angle: while building an installer profile I found it was tedious and wasteful that I had to export and generate data structures on all ends of Drupal and then wind up with a set of associative arrays in my profile file of which only I knew where they're coming from: the ideal solution would internally _know_ which export function matches which import function.
This simple bit of information about what import function matches which export function allows us to do various things like the push deployment that the deploy module implements or generating install functions like the installer profile wizard of the Install profile API (http://drupal.org/project/install_profile_api ) or just keeping a site configuration in version controlled code.
This simple notion of symmetrical import/export function pairs on a per module level together with a wide usage (deployment, installer profiles, version control, etc.) could be a great driver for more and more import/export function implementations for site structure and content. This is going to be very important, because nobody will be able to build import/export functions on their own, but as a community we can. A very wide basis of use cases for this core functionality is therefore crucial...
Overlap - break out?
Very Nice.
Actually, I should have done better digging before my last weekend's work: http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/alex_b/port/
Take a look at this implementation of a "port" and see how similar our concepts are:
http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/alex_b/port...
:)
The port module does a subset of what the deployment framework does. The notion of 'symmetry' of export and import functions is very powerful and can be used for not only deployment - and this actually brings me to my point: I'd like to suggest to break out this functionality of deploy module.
With port.module I came from a different angle: while building an installer profile I found it was tedious and wasteful that I had to export and generate data structures on all ends of Drupal and then wind up with a set of associative arrays in my profile file of which only I knew where they're coming from: the ideal solution would internally _know_ which export function matches which import function.
This simple bit of information about what import function matches which export function allows us to do various things like the push deployment that the deploy module implements or generating install functions like the installer profile wizard of the Install profile API (http://drupal.org/project/install_profile_api ) or just keeping a site configuration in version controlled code.
This simple notion of symmetrical import/export function pairs on a per module level together with a wide usage (deployment, installer profiles, version control, etc.) could be a great driver for more and more import/export function implementations for site structure and content. This is going to be very important, because nobody will be able to build import/export functions on their own, but as a community we can. A very wide basis of use cases for this core functionality is therefore crucial...
Looking forward to your thoughts,
cheers and again: awesome module,
Alex