Re: Data::ShortNameProvider proposal

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.