Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Some early comments about this list of APIs

  • Surely there is one reason for inventing this, completely bypassing the existing components (both for plugins, subplugins and subsystems). But I cannot really imagine it. Why not use direct mapping between components and APIs ? Code is going to use ones and docs are going to use another?
  • More yet, I don't get why the list of APIs ignores everything that is provided with plugin abilitites. Aren't "auth" or "enrol" or "reports" valid core APIs? In fact I think that the parts of Moodle currently working under the "plugins umbrella" are the most formal APIs we have in codebase (at least the OOP ones).
  • Some of the APIs in the list seem incorrect, inaccurate:
    • database API. it should be split, for sure in ddl and dml APIs at least.
    • time API. => datetime, surely.
    • renderer API => is that really an API
    • upgrade API => WTF is that? I'm specially interested on that, as far as it seems I'm the man in charge of documenting it and I don't know what the hell it is (MDL-30971).
    • grade and grading APIs => Should we have also group and grouping APIs? (sorry, joking, hehe, but don't buy the difference).
    • preference API : set/get/remove_user_preference() functions?
    • ...
    • ...

So, in summary, I don't get which benefits this new list provides, nor thing we are doing well by keeping apart some APIs because them being "pluggable", nor I think the APIs are well balanced at all. Just my 2cents (really not destructive, but constructive, although it sounds the opposite, guys).

--Eloy Lafuente (stronk7) 05:52, 5 January 2012 (WST)