Some general remarks: * Resource and Services are perfectly abstract names but its hard to imagine for a user what they mean. I'm in favor of more specific names, to make it easier for users to imagine what they stand for (I only have to figure out what the right names would be).
A valid criticism, but it's a little late in the game for that.
* As Dare Obasanjo already mentioned the tying of services to collections is not very practical. I think this is definitly something that should be changed.
I disagree. A Service is a Collection augmentation mechanism and may be exposed with multiple implementations of the same interface depending on which collection it is augmenting, which would especially be important for servers whose underlying data model is aggregated from a variety of sources. To say that it shouldn't be associated with individual collections makes it much more difficult to implement.
Interface specific remarks:
Collection interface
* I think the behavior and interface of the getServices method should be changed, because: - Each instance of a service could possibly take up resources, in which case you would want to instantiate those services lazy whenever getService is called.
This is an implementation issue, and can be addressed specifically be a vendor and their own needs. Just as your concern about where collection associates should be... There's nothing barring someone from having a single instance of the same service, and having the Collection implementations resolve to that same instance... Or to lazily instantiate a service upon request.
* I'm not quite sure about the use of getResourceCount/getChildCollectionCount, since in the case of X-Hive it involves counting the resources which of course has a bad performance characteristic.
Bad characteristic for X-Hive, but not other DBs. This is not a problem for Xindice, and probably won't be a problem for systems like Tamino and many relationally mapped XML-DBs. You can always throw an exception.
CollectionManagementService interface
* If think this interface is overkill, why not add the createCollection and removeCollection methods to the CollectionInterface? If not should it then check if the collection it operates on is still open?
This is a sticky issue no matter what, because the way most vendors implement collection management is different, though the way most people access the content of a collection is fairly consistent. For example, how would you propose a generic way to create a collection based on relational mapping? It's not very simple, which is why decoupling the two functionalities and allowing a vendor to write a proprietary collection management service if necessary seemed like to most appropriate solution.
* getIterator returns a ResourceIterator. I'm more in favor of returning a java.util.Iterator (I don't see the cast that becomes necessary as a problem), and renaming the method to iterator() because that's more like other java interfaces, though I understand that this just a matter of taste, and having an own interface for it could make porting the API to other platforms than java easier.
The primary goal of the API is to be platform and language independent, which is why I'm sure people who are implementing the API in Python or C++ wouldn't have agreed with you.
* The ResourceIterator interface If not replaced by java.util.Iterator I would prefer if this interface would have methods named next() and hasNext() instead of nextResource() and hasMoreResources().
Why not write an Adapter that implements the Java Iterator interface and wraps the ResourceIterator?
-- 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/ ----------------------------------------------------------------------
