Hi,

I'm working on a project which, roughly, must provide the following capabilities:

1) Users of the service can create their own private document collection.
2) Users can add/remove/update documents within their collection, at will.
3) Users can optionally open up their collection to others, using highly granular ACL's for read and write operations. (e.g. "The public can read this document (or this class of document). Also, users A, B, and C can read or write this other document (or this other class of document)").

We are investigating both XML:DB API, and Xindice, as a possible API foundation and/or actual back-end implementation to meet these requirements. Admittedly I am new to both of these projects. In browsing the available materials this afternoon, I found nothing in either XML:DB API or Xindice which knows about users, permissions, etc, except at the whole collection level (not granular enough for us).  I am assuming then that this kind of functionality isn't available out of the box.

My question for this group is, if I were to use XML:DB API (and probably Xindice), how roughly would I go about designing this enhancement? I can think of two approaches but I don't know enough to say which is the "better" approach:

(1) We develop an XML:DB API "shim" layer - our own implementation of XML:DB API which is a filter for a "real" XML:DB API implementation (such as Xindice's), adding authorization checks to every API command (assuming some security context has already been established). This is similar to the approach that JDBC connection pools take - they implement the JDBC interface as a shallow pass-through to a real JDBC provider, adding pooling functionality in the process.

(2) We do this at the application level - e.g. choose an implementation (such as Xindice) and dig in deep - modify the sources to add this kind of functionality.

or, (3), I'm way off base here and am better off starting from scratch than trying to do this with XML:DB API/Xindice

Opinions would be greatly appreciated,

Thank you,

Bryan

Reply via email to