From: David Jordan > Hi Tony > I partly agree with you. But I should be able to > process xml data in UniVerse far simpler than at the > moment. I should not have to read xml in one > application, convert it to a dynamic string and then > send it to universe/unidata, I should just be able to > do it one step. This is a failing of Rocket to > provide suitable interfaces to unibasic.
(In my last note here of the day... YAY!) David, we actually do agree. My position has always been that the DBMS vendors need to provide us with connectivity that makes it easy for us to make use of specialized tools. If they were to just do that effectively, then they wouldn't need to keep trying to create their own unique functionality, with varying degrees of success. They could spend more time focusing on the things that only they can do, like making a great DBMS even better. Coincidentally, earlier today I was prompted to make the exact same comment in the QM forum to Martin Phillips. The paragraphs below came from that note. My intent there is on making it easier for "us" to add value to the DBMS, where above I'm saying Rocket should add connectivity which allows "us" to connect to outside tools to add value. It's all the same. T ========= ..... changes should strive toward facilitating developer independence. In other words, rather than just implementing X for release a.b-c, consider implementing tools which allow others to implement X, and Y, and Z. As you implement X, consider what changes to the underpinnings of X would allow developers in the field to later do Y and Z. Your single development effort will go a lot further as you implement extensibility rather than just features. ... Sure, features are required, but there's always a new feature for which users are going to be dependent on you, and that takes your time from more significant efforts. Your skills (IMHO) should be utilized for making a better database engine, not so much for adding features on top of that engine - though of course there is considerable overlapping area there. And again, I wish other companies also followed this model. I'm reminded of the OO principle, code to the interface, not the implementation. The DBMS needs to be a huge collection of abstract base classes on which we can build, where traditionally we get a steady diet of cool but isolated concrete classes. (That may only make sense to people who have read about design patterns.) ========= _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
