I don't mean to disparage aD at all, there is some truly wonderful code and substrates in the ACS. But the "aD develops the ACS" days brought a rushed and incomplete toolkit out, and some of that rush can be seen in the names and ways the API has changed from release to release.
So I think there's more than just a political benefit to renaming portions of the API. I believe that with some simple name changes from ad_ to acs_ we can make life easier for developers (new and old) to learn and use the API. It will make the absence of doc, that much more palatable. Sigh.
We started with proc, we moved to proc_doc, we're now at ad_proc. You're a newcomer wandering through legacy code, which do you use?
We started with set_the_usual_variables, moved to ad_page_variables and page_validation, and then moved to ad_page_contract. You're a newcomer wandering through the legacy code, which do you use?
Don't forget how ad_proc itself can help with easy, unbreaking compatibility. ad_proc lets us very easily mark procedures as deprecated letting us keep that procedure around for a release or two.
In short, as part of the emergence of OpenACS as the premier ACS implementation, renaming legacy procs from ad_ to acs_ will provide newcomers a welcome foot hold when wading into the river of ACS development.
