Brion, I agree that API should not duplicate DB access, but unfortunately most of the core code was targeted towards a single page request. Only some special pages return data for multiple items, and from what I understood, they are not easy to refactor to just get the data for the API (I might be wrong). Hence most normal wiki operations seem to be a special subset the theoretical internal API (e.g. just need content of a single page whereas API may provide content of multiple pages) - which validates the separate biz logic tier idea.
On 6/15/07, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yuri Astrakhan wrote:
Having WebDAV interface sounds very very cool, but under no circumstances should we introduce yet another direct database access layer.
At present, Wiki is a web based single tier application -- the code that modifies the databases is intermixed with the UI code that renders web pages.
The API has to duplicate some of the db access logic, together with various security validations, to provide useful services.
The machine-readable API should *never* be duplicating any database access logic. Any remaining cases where DB code is intermixed with UI need to be refactored, as have been many places in the code already.
As I recommended before, and as I continue to recommend, nothing should be going into the API without doing that refactoring. Any time you add new DB code into the API, it's a mistake.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGcpr0wRnhpk1wk44RArpGAKCDeyi0RLMXU6JF4V3fuqkeqnkLRwCgm+bN ZoJboufUWdg0p9UjTmwg9y0= =BtA/ -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l