There have been various attempts at upgrading api.module to Drupal 6.x. However, it is a complex module, and until now, none of the attempts has yielded satisfying results. We now have the situation that there are 16 patches in the patch queue, none of them thoroughly reviewed, leaving anyone trying to help on this issue without much help and probably causing her to start from scratch again (at least thats what happened to me). Thats why i think we need to break down this issue into smaller tasks. Smaller tasks can more easily be solved, tested, and reviewed. After a subtask is finished, it can be commited to CVS HEAD, giving anyone else a solid starting point for further tasks, without worrying about the base she is working on.
Tasks
- api.info. trivial.
- api.install. there are 6 patches for this in the queue. to be tested, reviewed, committed.
- api.module. the beast. i think this needs at least 2 subtasks:
- general Drupal 6 compatibility. for this i would recommend installing coder.module, checking "Converting 5.x modules to 6.x", and fixing all there errors appearing there. note that even if coder doesn't indicate errors anymore, it probably can still be improved or coded more elegantly.
- api_menu(). i think the way to go for api_menu() is a complete rewrite. it is grown organically and currently exposes 24 menu entries, many of them dynamic. while it would be possible to make it Drupal 6 compatible with some big regular expressions (i did), i think the clean way is to completely overhaul it and use Drupal 6's Dynamic Arguments (Wildcards) and Inheritance rules properly (if i would know how to do this, i would have done it :S).
- parser.inc
- mostly "general Drupal 6 compatibility", see above.
Issues and patches for these subtasks should be filed separately with the prefix "Drupal 6: ".
Future work
- Windows compatibility. Api.module currently doesn't work on windows because it uses linux path conventions. To enable windows users to help in the upgrade, (part of) my windows compatibilty patch should be committed.
- parser.inc should be cleaned up
+clearly separate parsing from database storage
+write unit tests for parsing functions
+maybe use a more lexical syntax analysis (probably using the tokenizer extension) instead of relying completely on regular expressions
+maybe standardize common regular expression components