Hello to Tim Bunce and Harry Jackson and Robert and whoever else is here. I don't know how many people are on [EMAIL PROTECTED] yet, but in the list's 18 message long archives, you 3 were the only posters (mainly you first two).
I have a strong interest in this Parrot DBI project and its ideals, and I would like to get in at the ground floor if possible. (I would have joined the list sooner, but I only learned about it today, from the latest summary on perl.com, which for some reason I didn't get in my mailbox like the ones from Jan 20th and before.) First off, I have read/skimmed through all of the messages at http://www.mail-archive.com/[EMAIL PROTECTED]/maillist.html , so I can see what you discussed so far. (The last message implies that you have postponed further talks to wait for Parrot itself to develop further.) I have also looked through Tim's advanced talk that was mentioned in his Announcement post. And I am reasonably familiar with how the DBI for Perl 5 works internally, though I have not written any drivers for it. Second off, I have a few (for now) questions: 1. I need some clarification regarding this text in the Announcement post: I anticipate that drivers will be implemented using the Parrot Native Call Interface (NCI) to interface with the underlying database API. This has the significant advantage, if it works well, that drivers shouldn't need to be compiled on each platform. Are you saying that one should be able to write PDBI drivers entirely in PASM or IMCC and they would actually be able to talk to the various database products, or do PDBI drivers actually need to be written in C? I would have expected that they need to be written in C, since the native database product drivers they talk to are only C-compatible; however, then the drivers *would* have to be compiled on each platform. But if they are entirely PASM or IMCC, then what features does Parrot provide that would magically talk to the native C libraries for each database product? 2. Is PDBI mainly meant to be a clone of the tried-and-true DBI for Perl 5, with a virtually identical feature set aside from the fact that it is meant to work with any language running on Parrot? Or do you truly desire to have some serious innovation in features and design over the "old world" framework, which would put a lot more power in the hands of users than they ever had before? And don't get me wrong here, I'm not discounting that multi-language use is a huge step forward by itself, along with the significant savings of labour that would have been spent making a separate clone for each language. It's just that, looking on an individual language basis, what I have seen so far implies that users will get the same features as before and not more or different. 3. Do you have any plans to use named bind variables (eg ":foo") rather than positional ones, like the current '?' design? I see a switch to named to be a relatively simple and yet very powerful improvement. For one thing, often the same value is used multiple times in a SQL statement; for another, it is rather tedious to keep track of long lists of '?' and keep them in sync between their appearances in the SQL passed to prepare() and the variable list in execute(). Third off, I have been working heavily on my own new database independence project for awhile now, which was first announced on CPAN 13 months ago, and which I have talked with Tim about a few times since then (mainly around last summer). While I have been prototyping my project in Perl 5, I have intended it all along to be used by applications written in any language, and link it to Parrot in particular. So far, there had been no attempt to make the existing DBI work with Parrot, that is, until the announcement of PDBI. My project was heavily influenced by "classic" DBI in its high level design, namely having a common interface that applications talk to, and database product specific drivers in the background to mediate between that interface and the native product interfaces. The "current" version of my project is at http://search.cpan.org/dist/Rosetta/ with several more large updates due in the next few days and weeks. In particular, I expect to have a version that you can actually use to talk to a database within a few weeks now. Most of my work so far was in design, working out the details for a long term API before implementing it. My point is that, depending on what your goals are with PDBI, I am hoping that you can utilize the work I did with Rosetta in order to speed development of a powerful PDBI. I know that in the medium to long run I wanted to have a support/developer network in my project as DBI does, but if we can combine efforts, then developers can work once and further the common good rather than having to choose. In this way, my work can help the community the most. On the other hand, if it is not among your goals to permit applications to use identical SQL for all database operations no matter which database product they talk to, then I would alternately like to keep my extra goals as a separate layer from the PDBI core, and work with you so that the two are desiged to interact efficiently. Likewise, if you have no plans to let applications written in compiled languages use the features of this database library. Keep in mind that my project is designed to have a very granular API that should map quite well to basic PASM or C; it is also expected that some developers will want to make "higher level" wrappers for it. Anyway, I hope that this email can spur discussion on this list. I would love to hear from you, and contribute often. Thank you and have a good day. -- Darren Duncan
