Talk:Core APIs: Difference between revisions
From MoodleDocs
m (Created page with "=== 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 a...") |
|||
| Line 1: | Line 1: | ||
=== Some early comments about this list of 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). | 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). | ||
--[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 05:52, 5 January 2012 (WST) | --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 05:52, 5 January 2012 (WST) | ||
Revision as of 21:52, 4 January 2012
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)
