On Tue, May 13, 2014 at 11:11:10PM +0100, Tim Bunce wrote: > > Sorry for the delay BooK. Here's a more concrete proposal for a > Data::ShortNameProvider module. >
Many thanks for the documentation and synopsis. I'll start working on it this week. https://github.com/book/Data-ShortNameProvider is already set up. > Create a name provider: > > $np = Data::ShortNameProvider->new( > style => 'Basic', # eg a subclass to allow alternative providers > prefix => 'dbit', > timestamp_format => 'YYMMDD', > max_name_length => 32, # croak if a longer name is generated > ); > So styles would be subclasses/plugin/etc. 'prefix' and 'timestamp_format' are attributes of the style. Speaking of attributes and classes, is there a preferred OO framework for DBIT? Moo? I like the max_name_length restriction. I suppose the default would be 0, i.e. "no limit". > timestamp_format => 'YYMMDD', For time formats, I am partial to strftime, but your example looks like CLDR. Is there a preference for the DBI project? Both formats support some strings that produce localized names, which are going to be difficult to parse back (other than with \w+). Well, "use at your own risk" is a fair warning. :-) It would probably easy to support both, simply by assuming that if the format contains a % sign, then it's strftime. Not sure it's worthwhile. > Generate a shortname: > > $name = $np->generate_new_name('foo'); # eg returns "dbit1_140513__foo" > > The 'Basic' format would be: $prefix $version _ $timestamp __ $name. Why the double underscore before $name? > Parse a generated shortname: > > $hash = $np->parse_generated_name($name); # eg to get date etc > > %$hash would contain something like > > { > version => 1, # version of the Basic format > timestamp_string => '140513', > timestamp_epoch => 1400017536, > name => 'foo' > } It should also return 'prefix', and actually all attributes needed to re-create the DSNP instance. So doing something like: $np2 = Data::ShortNameProvider->new( %$hash ); would ignore unexpected parameters (timestamp_* and name), and return a Data::ShortNameProvider object equivalent to the original one. Regarding timestamps, a timestamp generated with 'YYMMDD' (day granularity) does not contain enough information to produce an epoch timestamp (second granularity). The obvious default would be to pick 00:00:00 (assuming UTC, but who in their right minds would use anything else than UTC for timestamps?), but that might cause issues if the timestamp is used to weed out old stuff (as stuff would get old somewhat faster). Resolving this can be left as an exercise to the library user for the moment. -- Philippe Bruhat (BooK) He who marries for money never marries for real. (Moral from Groo The Wanderer #42 (Epic))
