Prepare for D7 port

For a new project I'm going to use this module. I do bot want to create a private fork, so I would like to give back all features I add. Of course this means that all these features will be generalized, made optional, customizable, have an upgrade path, etc. I also offer to maintain these features. But speed of development will be high. So I'm thinking about creating a D7 port and starting from there.

To facilitate future porting of features and bug solvings between D6 and D7 versions, I would like to start with a number of changes on the D6 version:

6.x-1.x-dev version:
- prepare for D7 (no E_STRICT warnings)
- apply Drupal coding standards where necessary
- run through coder module
- prepare for hook changes (Code in cases in D6 hook_nodeapi switch cases will be moved to hook_nodeapi_ methods that will be more or less) D7 compliant)
- prepare for DB api changes (by extracting all db code to separate methods)
- extract code that will be different in D7 into their own methods (especially all database access)
- split code over several files: *.admin.inc, *.pages.inc, *.edit.inc. Code size will grow, so splitting over multiple files will make it more understandable, maintainable and more performant (not included and compiled when not needed).

7.x-1.x-dev version:
- port to D7
- no changes in functionality
- tested and working

7.x-2.x-dev version:
- add features one by one
- thus 1 issue per feature with patch that will be committed to 7.x-2.x-dev head
- thus patches for the separate issues are built on top of each other

This way I hope to get 2 code bases that are as much the same as possible, making the job of (back)porting a lot easier

Questions to the current maintainers:
- What do yo think of this plan?
- Can and are you willing to spend some time to keep up with the subsequent changes that will come (i.e relatively short review - test - commit cycles)?
- Is there active work on other issues that might get hindered by this?
- Would it be handy to give me commit access (on D7 branches only, if possible) (I know, I will have to learn cvs for the few weeks that it remains in operation)
- Looking at the history of other issues (e.g. #331151: Ability to use javascript to select availability dates?) I get the idea that it is not easy to work with bursts of features by people who are not maintainer of the module. So I hope to have provided a structured way of handling all these new features to come in a small amount of time. Benefit for me and my client is that we don't end up with a private fork and that we can enjoy from future improvements from others.