On Thu, May 15, 2014 at 01:34:21AM +0200, Philippe Bruhat (BooK) wrote:
> 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.
Great!
> > 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.
I think either subclass or delegation (has-a) would be the best fit.
And between the two I think I'd prefer delegation as that makes it
easier to evolve the external API and internal API separately.
We should provide a base class for the delegated style class
which would also aid evolution and provide a range of services.
That way the actual style modules should be very small.
> 'prefix' and 'timestamp_format' are attributes of the style.
Yes. max_name_length can be enforced by Data::ShortNameProvider
by checking what the delegated generate_new_name has returned.
> Speaking of attributes and classes, is there
> a preferred OO framework for DBIT? Moo?
Yes, we decided Moo was ok as a dependency.
> I like the max_name_length restriction. I suppose the default would be
> 0, i.e. "no limit".
I'm inclined to make it mandatory parameter so people have to at least
think about it. We're calling it a _short_ name after all :)
> > 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?
I'd like to keep the dependency count very low, so for the Basic style
we'd only support a few hard-coded formats, so zero dependencies.
Perhaps a good trick would be to support a few hard-coded CLDR formats
or even just one initially, and then, if given an unrecognized format,
require a CLDR module let that handle the formatting.
> > 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?
It's part of the strategy to reduce the risk of clashes with existing names.
> > 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.
Interesting. Actually timestamp_epoch could be used to provide the
time value that should be formatted into the short name.
> 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.
That's by design. Just needs to be documented.
Thanks BooK!
Tim.
