I am replying to all 4 of Harry's emails with this one, or if I split it will be based on subject rather than original message. (The previous one on email formatting being a case in point.)
At 5:29 PM +0000 2/8/04, Harry Jackson wrote: >I do not see the Pure Perl driver and the XS version as contradictory. I see them as >complimentary. What I meant to say was that the existing DBI was available in 2 copies; there are 2 fully redundant code bases to keep in sync. The XS version was faster and inherantly more compatible, as most native drivers being interfaced with were in C or similar. The Perl version is easier to install in that there is nothing to compile, and people that just know Perl can write drivers for it. My hope was that with PDBI there would just be 1 copy, which would have both of the above advantages. Drivers for it could either talk to C, or talk to drivers written in any Parrot-hosted language, including Perl. My current impression is that this is the case, with a single IMC version. At 4:55 PM +0000 2/8/04, Harry Jackson wrote: >Jeremy Brinkley wrote: >>I'll comment that for my money merely having DBI-style functionality >>available for other languages is enormously worth it, I'd argue the >>successful design of the DBI argues against changing its core features. >>OTOH extensibility is a good thing, so perhaps providing easy ways to >>extend the DBI is the way to go. > >It is a very mature product and as you say its success is a good indication that it >must be doing something right ;-) That is true. I agree that the basic design is very sound, and the current implementation is battle tested, very stable, and has lasted a decade. However, I also know that people get ingrained or complacent in their habits and often think that the status quo is 'good enough'. People don't like change as it can push them out of their comfort zones. I also know that society and technology would be no where near as advanced as it is, or advance at all, if it weren't for the few people with radical or different ideas that are willing to challenge the status quo. At the same time, though, people often yearn for something 'better' than the status quo, even if they hesitate to embrace it when that comes. I believe that I am or will be offering an evolutionary advance over the established DBI which is significant enough to warrant general use or become a defacto standard. It will be both significantly different from the established DBI, and yet very familiar. >I would very much doubt that users will see a radical new DBI, besides, we are meant >to be discussing the Parrot Database Interface PDBI layer which I doubt users are >going to see at all. The DBI layer that will be written for each language is a long >way off. > >What we might see if we get the PDBI layer working well is languages having more >frontend modules or libs that use the PDBI You are exactly right. And in fact, I *expect* that my evolution of DBI will be buried under front end modules that are what typical users actually see, just as DBI is in practice. (I mean that anyone who uses DBI directly for more than something trivial tends to write a few mediating or wrapper functions of their own that simplify its use.) One analogy of how my evolved DBI would relate to the established DBI or to users of either is to look at the Parrot project itself. Writing code to use DBI directly is like writing in PASM. Writing code to use my version is like writing to IMC. But typical users wouldn't write to either; they would write in a high level language that Parrot hosts, and only the compiler writers for those languages would talk to PASM or IMC. The various front end modules or libraries are like the high level languages. So I see my additions sitting down there and making everyone's job an order of magnitude easier, while giving the same amount of 'control' (which they desire) as they have without my presence. >I would be pleasantly suprised to see a better design. > >If you have a radical idea then come up with a proposal and I am sure that there are >enough people on here to discuss it. As far as completely changing the DBI is >concerned I would be all ears to anyone who can come up with a better framework given >the complexity of the task. That's what I expect to deliver. I would be naive to say its a new paradigm, but I should be able to say that its a significant evolutionary step. My proposal, as it is currently rendered, takes the form of a documented example, which I am posting to CPAN regularly. While the current release 22 is a huge improvement for understanding over 21, I might recommend you wait a few more releases before being too critical of it. By then I will have actually used the prototype in a 'production' environment and so the most obvious design problems would be worked out. I'll post another announcement when the 'being used' version is up. At 4:39 PM +0000 2/8/04, Harry Jackson wrote: >Can you be more spefic about what you mean by "identical SQL". Are you >suggesting that we try and follow a standard like SQL/92 or SQL3. To quote CJ Date, >"products typically support what might be called a 'superset of a subset' of SQL/92". >Several of the larger database have been trying, some harder than others and each and >every one unsuccessfully, to adhere to the SQL/92 standard and the SQL3 standard is >much bigger. It would be great if we where all able to use the same SQL for all our >operations no matter what the database but this is no easy task. When I say, 'identical SQL', I mean that you can take an application of nearly any complexity level that works with, say Oracle, then change just the 'connect' string and nothing else, so that it uses Sybase or DB2 or PostgreSQL etc, and the application will continue to "just work". It is as if every database product out there has full SQL-1999 or or SQL-1992 or SQL-2003 compliance, so you write in standard SQL and it just works anywhere. When it comes down to it, letting an application "just work", without changes, when moved between databases, is the point of my evolution. The current DBI accomplishes part of the goal, but since SQL is different everywhere, that is the major stumbling block in using it for non-trivial application portability. At the same time, however, I realize that database features and even the SQL standard is very large and complex, and bigger than I can handle. So I am going the typical route of porters before me such that I address only a piece of the problem. However, where the other efforts allow maybe 50% of the code in a on-trivial application to be portable, I expect my solution to go to 90% or 99% (or in some cases, 100%) for large applications. See the file Language.pod that is in my current distribution for an outline of what I plan to address or not address. >How would you propose we should approach such a task bearing in mind that the >database world all use and understand what they need of SQL and would not take too >kindly to changing to something that looked even remotely different. To this I say, use a wrapper. My effort is designed so that a wrapper could be easily made for it that would emulate any previously existing database interface, so code or users that prefer those don't have to change. As a case in point for this sort of thing, Tim maintains an Oraperl emulator over DBI. To me, an API emulator is just another kind of 'frontend module'. >On the other hand there is also ODBC. Yes. I sometimes liken my effort to what ODBC does. However, in my experience ODBC is much like the current DBI, where it just passes through the SQL you still have to write yourself, differently for each backend database. If anything, ODBC seems to be more of a network protocol, much like how you use DBI's ProxyServer and ProxyClient. >If we manage to get a clone with everything working as well as it is >today I would be fairly happy. As for extra features being added to the DBI I would >first try the DBI dev mailing list. I am sure they are open to sugestions for new >features that would enhance the DBI. Tim has already asked people if they have any >feature requests etc that they would like to see in version 2 (If I am not mistaken). >If it cannot be added at that point for whatever reason and everyone agrees that it >would be a great feature then bring it up here where it might become a possibility or >at least it can be investigated. > >One of the reasons for this mailing list is to see what people would like added where >possible. For all practical intent, I expect that the Perl-native prototype I have underway, which sits on top of a standard DBI interface, will be how I extend the existing DBI. I'm not trying to hard to get large feature changes into that, as I see its developmental lifespan being limited to the time that people do not migrate to Parrot. Similarly, I pay little attention to perl5-porters or dbi-dev as they are mostly filled with discussions about 'the way things are'. More specifically, I am willing to make numerous suggestions for improvements of current-DBI, such as adding full support for named bind variables, and adding full support for Unicode encoded SQL, but I won't be spending much time in trying to implement them. Rather, I am focusing my efforts on the Parrot frontier, where I see myself being able to do the most good for the community, and where I am the most interested personally. It is in the current PDBI project that I am willing to invest my time and code, even in a 'clone' (the code itself is completely different, even if the feature set is the same). Among other things, I'll see if I can add drivers for some database products that aren't supported yet. (My now-out-of-date Framework.pod lists maybe 50 of them.) Note that, one of my big suggestions for Tim around May of last year was that a DBI version 2 could be a pure C library with separate add on bindings for Perl 5 or Parrot or other environment du jour; no XS in the core. However, now that I know about Parrot's NCI and a pure IMC PDBI, I'm not sure if my suggestion will be useful any more. The main benefit of a pure-C DBI is its use with compiled programs. But PDBI would take care of practically all interpreted languages. Anyway, lets keep up the good work. -- Darren Duncan
