I am all for making flexible API that can be easily enhanced, but I am against making everything protected or especially public - classes have some interdependency that needs to be preserved in order for the API to remain stable. Individual classes are not meant to be instantiated individually -- they are designed to be instantiated by the main api module. Extending classes and adding them to the list of available modules is fine.
Limits: yes, they should be configurable by global settings. mModules: At this point I think a hook would be most suitable to allow extensions to change the list. Please outline all usage cases at the http://www.mediawiki.org/wiki/API:Calling_internally and/or discuss it on the talk page. Usage case example: Using from a command line, how inputs are parsed, additional options, the output format, etc. Thanks! On 7/16/07, Jim Wilson <[EMAIL PROTECTED]> wrote: > After having much difficulty using the API classes from a programmatic > standpoint, I've summarized my complaints into bug 10602: > > http://bugzilla.wikimedia.org/show_bug.cgi?id=10602 > > If you have any thoughts, please feel free to post a comment there. :) > > -- Jim R. Wilson (jimbojw) > > _______________________________________________ > Mediawiki-api mailing list > [email protected] > http://lists.wikimedia.org/mailman/listinfo/mediawiki-api > > _______________________________________________ Mediawiki-api mailing list [email protected] http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
