Hi Jonathan, Am 08.11.2013 um 02:59 schrieb djg...@gmail.com:
> I hope my reply comes across correctly. Depends on your intension ;) I’d say: yes. >> Hi Jens and Sven, >> >> I understand that AnyData needs a reset. What is consensus if direction? >> >> For my project I need to manage a big variety of source formats, so I'll be >> willing to participate in redesign or coding of AnyData if need be. >> Otherwise >> I'll have to dream up my own data format abstraction layer. >> >> There are generally four types of sources or formats in my environment >> >> Databases accessible through DBI >> Databases accessible through command line binaries >> Records based files, such as csv >> Table based files, such as /etc/hosts, json etc. >> >> Any lessons we can stage from Augeas and it's concept of lenses? Or just >> bridge >> between Augeas and DBI? >> > > I just started looking into AnyData since I didn’t like all the work I was > doing to use the template feature of unpack then while processing building a > SQLite in-memory/file DB. I am thinking DBD::AnyData would be better and > easier to maintain than what I have built > > I notice DBD::AnyData doesn’t work with DBI > 1.622. I am willing to help but > not sure where to start. I may try to build a proof of concept from an older > DBI to see if it will be any faster/easier to maintain that what I am doing > now. I would recommend 1st to join IRC - at irc.perl.org in #dbi channel. If this is an absolute no-go, maybe a Hangout on Google+ would work better? However - the first step should be to read the concept and api of DBI::DBD::SqlEngine::(Table|Data)Source. I would favor this API even for AnyData and it’s storage backends. Let’s together develop an API on-top of it for parsing, if necessary. When AnyData got rid of the internal Tie stuff, a reintegration of DBD::AnyData into DBD::File will be a smooth way. Cheers -- Jens Rehsack rehs...@gmail.com
