I'll post, if only to prove there are more than three subscribers to the list. :)
On Sat, Feb 07, 2004 at 04:18:54AM -0800, Darren Duncan wrote: > 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? The NCI should allow most libraries to be loaded and called into without wrapping with C glue; but some, depending on their quirkiness, may require a wrapper in C. > 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? The underlying platform's dynamic loading mechanism. Check out docs/pdds/pdd16_native_call.pod. > 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. 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. > Third off, I have been working heavily on my own new database > independence project for awhile now, ... > 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. It would seem to me that query generation is naturally a separate thing from communication. On the other hand, I think it would be a useful feature for the DBDI to provide hooks at various stages of statement handling, allowing separate small modules to provide things like query rewriting or data-dependent connection dispatch. This might very well be a current feature of the DBI; I haven't checked in in a while. -- Chair of Quantum Non-binary Accumulators Louden Nelson Memorial Tea Club of Santa Cruz
