On Mon, Apr 5, 2010 at 11:29 PM, Tim Bunce <tim.bu...@pobox.com> wrote:
> "Data" is fairly meaningless as a name. The Data:: is intended to be > used for modules that work with abstract data values: Data::Bind, > Data::Bucket, Data::BitMask, Data::COW etc. > Thank you for taking the time to comment! Meanwhile, while writing all the docs in order to be able to release properly to CPAN, I've also renamed it to Data::Collector. I think it's a more accurate term than Data::Scanner, since it doesn't really "scan" anything. It provides a small framework for collecting information. > There's a Sys:: namespace that has things like Sys::Info. (Perhaps you > could integrate with that.) > Even though I will be using this in a system environment (trying to get information on the system - where Sys::Info might be useful), Data::Collector was built with flexibility in mind, and can be used for things not related to a system at all. You could write Data::Collector::Info::Dilbert to have a piece of info that fetches Dilbert comics, for example. You could have a Data::Collector::Info::MyCorpIncCustomerInfo and so on. Pretty much like plugins so anything homegrown can be used with it without altering anything. I reckon that's why settling down to a specific type of data will not be right. > Generally speaking the more specialized the module the more > words-per-level the name should have. > I reckon that is why Sys::Collector is probably not a good bet, since it's not necessarily system information. It gets even trickier since the data can be returned in various forms (XML, JSON, Data::Dumper. YAML, Perl objects - these I had already implemented as Data::Collector core serializing engines along the way). Thanks again, I appreciate the response, it helped me understand it more. "Abstract data values" seems like what I'm going for, so it looks like a good match. S.
