Duh. I meant, go with (1) 

:) 

--- Bryan Field-Elliot <[EMAIL PROTECTED]>
wrote:
> Good advice -- but when you said, "I'd go with (2)",
> did you actually
> mean, "I'd go with (1)"? Everything else you've said
> would indicate
> thus....
> 
> Bryan
> 
> 
> On Tue, 2002-04-16 at 17:21, Dare Obasanjo wrote:
> 
>     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/
>    
>
----------------------------------------------------------------------
>     
> 


=====
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/
----------------------------------------------------------------------

Reply via email to