It depends on what you mean by DB access tier. I thought that usually ment database vendor independence, whereas business logic tier would handle:
* authentication * retrieval of "object oriented" data in raw wiki markup, both single page and in bulk, lists, system settings, etc. * access rights validation * committing changes back to DB * Markup => HTML rendering should be a separate library. This way both Web clients and API may convert wiki markup into HTML, even as a non-db-commiting service (converts input markup into HTML).
An API layer on top should provide access for external applications as well as cross-wiki transclusions and HTML rendering services.
The regular web interface should never directly access the DB, but only use the biz-logic tier. Alternative UI such as WAP would follow the same pattern.
--Yurik
On 6/15/07, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yuri Astrakhan wrote:
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.
Seems to me it validates refactoring the db access tier.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGctaLwRnhpk1wk44RAsCFAKCT0SySOTkC1z/qf9O4urUVCgPM0ACeNgux +xYDr29+3a72CBw7f1X2kv0= =2NdX -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l