2010/7/24 Jeff Zucker <j...@vpservices.com>: > Hi Jens, > > I will try to give you a more detailed response next week but here is a > short answer in the meantime. AnyData (as distinct from DBD::AnyData) was > meant to be used without DBI so it's storage and other mechanisms are > separate and are all based on tied hashes. DBD::AnyData tried to support > users making their own storage mechanisms but unfortunately not using > standard sub-classing so it's a bit kludgey. It mostly works like DBD::File > but as you've probably learned would be better if it switched to DBD::File > style interface and allow proper subclassing. I can give you some pointers > there.
That would be great and I expect that it will help much. > If you have more specific questions, ask away, otherwise I'll try to > dig into it again (it's been a while) as soon as I can. I will ask when I have more specific questions. Currently I try to understand the overall picture. > I'm afraid I've only skimmed the dbi-dev postings and have not really > followed what you've done with the modules except to note that you're making > many improvements. One of these days I'll need to download the latest > versions and see what you've done. You handed over the maintainership, because you're much to busy with your job etc. Would be great having you back on board one day. Best regards, Jens > Hope all is well. > > -- > Jeff > > On Sun, Jul 18, 2010 at 3:33 AM, Jens Rehsack <rehs...@googlemail.com> > wrote: >> >> Dear Jeff, >> >> I hope you're not completely off for Perl5 development. Maybe you are >> still >> subscribed on dbi-dev@perl.org and see our progress of the last months >> and weeks thanks to your great groundwork. >> >> Unfortunately I cannot improve AnyData and DBD::AnyData as I wanted, >> it's much to complex. I fixed DBD::AnyData for DBI-1.612 of course, as >> I promised and for what I received the co-maintainership from you. >> >> I see that AnyData has a complete own storage backend and will always >> use it, even in case of DBD::AnyData - what makes it not reasonable to >> derive from DBD::File (for current implementation). >> >> I want to understand (and improve) following parts (beside the general >> picture): >> 1) How is the abstraction of the storage meant? Would it be possible to >> have >> storage abstractions in DBD::File which can be used instead (or to >> extend >> such a storage)? >> 2) Could you paint me a picture (UML, Dia or just words) how the parser, >> storage (especially the AnyData::Storage::TiedHash) work together? >> >> Any help is very welcome, I'd love to bring DBD::AnyData beside DBD::Sys >> as a meta driver for all important data beside OS internal (and related) >> tables. >> >> Best regards and thanks in advance, >> Jens > >
