On Thursday, February 7, 2002, at 02:40 PM, Tom Bradford wrote:
On Thursday, February 7, 2002, at 02:30 PM, Dare Obasanjo wrote:This can easily be supported by doing what I did with SiXDML. Just add getService(String, String) to the Database class.
Here's the problem with that though. Imagine you have a program that performs service requests in a generic fashion against Collections that are passed to it. Now furthermore, say you have two collections, one is a collection that is relationally mapped, the other that is native. Because of this, the Service may have to be implemented completely differently. When you request a Service of the same name, you'll be getting back the same interface, but with a different underlying implementation.
It's awkward enough that you'd have to query the Collection for its absolute path, and then pass that absolute path to the Database to resolve the Service, but add to that the fact that when you offload Service resolution responsibilities to the Database, you're asking it not only to get a Service, but to get a specific implementation based on the Collection name you're passing to it, which is more responsibility than the Database needs to handle, especially in a system where the collection structure is based on many heterogeneous data sources and implementations.
I don't think he was suggesting that this should be the only way to access collections just an addendum.
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.
-- Tom Bradford - http://www.tbradford.org Apache Xindice (Native XML Database) - http://xml.apache.org Project Labrador (Web Services Framework) - http://notdotnet.org
---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
Kimbro Staken XML Database Software, Consulting and Writing http://www.xmldatabases.org/
---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
