Talk:Core APIs

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 what 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)