Hi, I'd go with (2) which is the approach I took with SiXDML. I chose that for a number of reasons,
a.) Faster ramp up time to learn APIs than learn how internals work. b.) Less dependance on internals of DB will mean that it less resistant to changes in the implementation since APIs typically stay consistent while internals do not in Open Source applications. c.) Easier to modify for both yourself and end users. d.) Users don't need a different build of Xindice to use your application and finally once the project proves useful the code can be moved into the DB internals for perf reasons if necessary. --- Bryan Field-Elliot <[EMAIL PROTECTED]> wrote: > 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 > > > ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #230 I will not procrastinate regarding any ritual granting immortality. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
