Re: Remarks about XML:DB API
On Friday, February 8, 2002, at 04:40 AM, Kimbro Staken wrote: It's widely used though, simply because dbXML, eXist and now Xindice use it. It may not be used in any big installations, but it is definitely used in a whole bunch of little ones. There's also one big installation that was decorating java.sun.com for a week or so. When it comes to API I tend to think less is more I agree. And I think Services are a great example of Less Is More. The Collection interfaces do the bare minimum as far as allowing access to the underlying data store. Services give vendors the option of providing more. the wrong path would have been trying to add querying, management, and transaction capabilities to the Collection interfaces themselves, as it would be a bold assumption to defined methods that people may never be capable of implementing, or may have to implement in a completely different fashion. So maybe we add Services to Database as well, but I think you very much underestimate their value at the Collection level. -- 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/ --
RE: Remarks about XML:DB API
> 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/ --
Re: Remarks about XML:DB API
On Fri, 8 Feb 2002 04:40:57 -0700 Kimbro Staken <[EMAIL PROTECTED]> wrote: > It's widely used though, simply because dbXML, eXist and now Xindice use > it. It may not be used in any big installations, but it is definitely used > in a whole bunch of little ones. > > I don't necessarily agree that it's too late to make some significant > changes though. We've never said the API is complete or stable. If the > changes are really necessary and improve things then we'll consider it, > though, the idea of changing names is one I'm not currently fond of. If I' > d seen a large amount of confusion from users I'd feel differently, but I > haven't really seen it. We've had the API in use for about a year and in > that time hundreds of people have used it. I absolutely agree here. BTW, we used the API in several proto types and smaller research projects so far. > > I just want to add one remark at this, which is more a practical matter. > > At X-Hive we initially also took the approach of creating "typed" > > iterators resolving in a huge amount of iterator classes, which > > essentially did nothing more than casting. At a certain point we decided > > to drop this approach, en just use java.util.Iterator, we did this > > because we feeled that these Iterator interface polluted both the > > documentation and the source code. > > > > I wish we could do this, unfortunately the API really does need to be > language independent. We could of course name things the same as Java ... yup, that's the point to pay attention! > since it is the most common implementation language. Whether it's really > worth doing or not I don't know. Lars. -- __ Lars Martin mailto:[EMAIL PROTECTED] SMB GmbHhttp://www.smb-tec.com -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Remarks about XML:DB API
On Friday, February 8, 2002, at 04:07 AM, Arno de Quaasteniet wrote: I can imagine that you didn't see it before. I probably also wouldn't have since X-Hive also has root collection :) Anyway, if there is a problem then it has to be solved. I need to think some more about you suggestions of extending the getService mthod with a context parameter. I personaly still have bad feeling about tying services to collections but that's more about intuition than about arguments (except the one mentioned earlier), so I have to examine it some more. Well as Dare pointed out that was a stupid idea, it didn't actually solve the problem at all. We're going to have to change the concepts around the Database instance to enable services at that level. I need to think about it more. Arno -- 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/ --
Re: Remarks about XML:DB API
On Friday, February 8, 2002, at 02:41 AM, Arno de Quaasteniet wrote: A valid criticism, but it's a little late in the game for that. You have a point about that but on the other hand the API isn't exactly widely adopted yet :) It's widely used though, simply because dbXML, eXist and now Xindice use it. It may not be used in any big installations, but it is definitely used in a whole bunch of little ones. I don't necessarily agree that it's too late to make some significant changes though. We've never said the API is complete or stable. If the changes are really necessary and improve things then we'll consider it, though, the idea of changing names is one I'm not currently fond of. If I' d seen a large amount of confusion from users I'd feel differently, but I haven't really seen it. We've had the API in use for about a year and in that time hundreds of people have used it. I think the getServices method is useless. It just adds an extra way to get a service object. I don't see the value of that. If its just for querying what services are supported then it should just stick to that. Though you could also check if a service exists by using the getService method, so even for that usage it would be unnecessary You're right, if that method does anything, it should probably return a list of service names rather then service instances. When it comes to API I tend to think less is more I agree. Wrapping of course is always possible, but not prefered at all. I just want to add one remark at this, which is more a practical matter. At X-Hive we initially also took the approach of creating "typed" iterators resolving in a huge amount of iterator classes, which essentially did nothing more than casting. At a certain point we decided to drop this approach, en just use java.util.Iterator, we did this because we feeled that these Iterator interface polluted both the documentation and the source code. I wish we could do this, unfortunately the API really does need to be language independent. We could of course name things the same as Java since it is the most common implementation language. Whether it's really worth doing or not I don't know. 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/ -- 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/ --
RE: Remarks about XML:DB API
> But I do see it as a problem, which was the point I was > trying to make > with my Oracle example. Ok. Sorry, for the misconception. > You and Dare are correct that Services tied > exclusively to collections are not intuitive and inadequate. > Understand > though that until I implemented the API on Oracle I'd done > two other impls. > One for Xindice and the reference impl. Both of those have full > hierarchies including a natural root so the problem wasn't > apparent. Now > it is obvious. I can imagine that you didn't see it before. I probably also wouldn't have since X-Hive also has root collection :) Anyway, if there is a problem then it has to be solved. I need to think some more about you suggestions of extending the getService mthod with a context parameter. I personaly still have bad feeling about tying services to collections but that's more about intuition than about arguments (except the one mentioned earlier), so I have to examine it some more. Arno -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Remarks about XML:DB API
On Friday, February 8, 2002, at 03:44 AM, Arno de Quaasteniet wrote: Having though about it some more I see a typical chicken/egg problem for creating the first collection... am I right about that? Besides that if your database doesn't support sub collections retrieving the CollectionManagerService from a collection seems a bit illogical. (something more or less already mentions by Dare, but I looks like you didn't see it as a real problem) But I do see it as a problem, which was the point I was trying to make with my Oracle example. You and Dare are correct that Services tied exclusively to collections are not intuitive and inadequate. Understand though that until I implemented the API on Oracle I'd done two other impls. One for Xindice and the reference impl. Both of those have full hierarchies including a natural root so the problem wasn't apparent. Now it is obvious. Regards, Arno -- 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/ --
RE: Remarks about XML:DB API
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Arno de Quaasteniet > Sent: 08 February, 2002 10:45 AM > To: [EMAIL PROTECTED] > Subject: RE: Remarks about XML:DB API > > > > The problem comes if there is no root collection. For > > instance I have an > > Oracle 9i impl where the collection hierarchy is flat. I had > > to synthesize > > a root collection in order to have a starting point to create > > collections. > > Ok. This is a good enough argument for me to justify the > existence of a > special interface for creating collections. Though this > wasn't the point > of your reply of course :) Having though about it some more I see a typical chicken/egg problem for creating the first collection... am I right about that? Besides that if your database doesn't support sub collections retrieving the CollectionManagerService from a collection seems a bit illogical. (something more or less already mentions by Dare, but I looks like you didn't see it as a real problem) Regards, Arno -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Remarks about XML:DB API
On Friday, February 8, 2002, at 01:23 AM, Dare Obasanjo wrote: 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. Heh, heh, and that's a problem? ;-) = 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/ -- 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/ --
Re: Remarks about XML:DB API
--- 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/ --
