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(a)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(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/wikitech-l