> 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.
One of the main problems I have with this concept is that in X-Hive we can not do anything related to persistent data without a transaction being active. This is a very fundamental issue for us, that we can not change. So there is no way in X-Hive to retrieve a collection without a transaction being active, but in the current API it's not possible to get a transaction service without having a collection. So for us this is yet another chicken/egg problem related to the services being tied to collections. The above might count as an implementation issue, and not so much as a conceptual (you can argue about that), but furthermore I see some other problems. For instance what if you want to make changes to several collections and these changes need to be atomic? Logically these changes then all need to be done within the same transaction, but when transactions are bound to a collection this seems not to be possible. I think that the essence is that in the current API the collection interface is behaving like a database. One example of this is that you authenticate when accessing a collection. I think it would be more logical to authenticate when you access a database. Regarding the argument that its important for servers whose underlying data model is aggregated from a variety of sources: I think that this would count as an implementation issue :) I think its has much to do with the way you look at it. If you design an API having the concept of a database, that can have multiple collections, then it's not logical to tie services to collections (independent of where those collections get their data from). If you see the collection as a database in itself than this might my logical, but then their shouldn't be something like a database interface because that makes thing confusing. Kind regards, Arno de Quaasteniet ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
