--- Kimbro Staken <[EMAIL PROTECTED]> wrote: > The one problem I do see with it is that it changes > the concept of the > Database. In the current API you shouldn't be using > the database instance > for anything beyond the initial setup. If we move > logic like getService > into it then you'll actually be using the Database > instance in other > places as well. Not a major problem, but not as > simple as just adding one > method. We'd probably need a method on Collection to > return the Database > instance. Or another option would be to change the > getService method to > enable specification of what scope the service > applies too. I almost like > that better. > > Collection.getService(name, version, scope) where > scope is one of three > values, database, collection, or hierachy. These > could be defined as > constants in the Service interface. Hierarchy would > apply to the > collection and all children of the collection. > > Either way would work though.
Except that the latter way now has the same get-a-collection-then-get-a-service-from-it mechanism that was the issue in the first place. ===== LAWS OF COMPUTER PROGRAMMING, VIII Any non-trivial program contains at least one bug. http://www.25hoursaday.com Carnage4Life (slashdot/advogato/kuro5hin) __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
