On 2014-02-09 19:12, Ken Barber wrote:
TL;DR - I want to specify the max values of integers and floats in the
puppet language for a number of reasons. Skip the background part
to get to "Questions and Proposal" if you are already familiar with
serialization formats, and issues regarding numeric representation.
TL;DR: from a PuppetDB perspective this is great, lets talk next steps
I think this direction is correct, and for PuppetDB we'd like to see
this clarified without a doubt. For those at home Henrik and I
discussed this at length of #puppet-dev on IRC, and its a complex
topic that extends beyond just numbers. So in fact other items such as
string length could also do with some clarification also, maximum
amount of entries in a hash or map etc. etc.. From our PuppetDB
perspective we often have a greater amount of concerns about
limitations and such than Puppet and establishing clear constraints
will definitely help our designs going forward.
For example right now we cannot support an arbitrary decimal length
for structured facts, we only support signed 64 bit big-endian
integers. This was on purpose to some degree, because it would add
complication to the design but in a way its a bug really and the lack
of guidelines do not make it a nice bug to solve. If the community can
make decisions about this stuff (which is why I've been sitting back
and reading the threads quietly before responding) we can then go
about to work on meeting those constraints that we define in our
design as well.
There is a lot however to be said about defining smaller constraints
rather than larger ones initially, even if some use-cases might break.
Gone are the days where we can be frivolous and allow unbounded
storage - because it hurts performance. In some cases it might not be
wise to for example, store an ISO image as base64 in a fact string
:-). By letting users do crazy stuff, it actually hurts them, and it
hurts us also as we have to develop solutions for edge cases that
probably aren't smart anyway ... taking time away from more critical
development items.
I think if you are okay with it Henrik, I'd like us to both formalize
this "schema" you propose in a design doc somewhere, and the PuppetDB
contributors should be more than happy to dive in and hack it to
pieces and add our concerns about whatever constraints we propose. ie.
lets talk next steps and make this real if we can.
That is great.
For the language - the specification is in the puppetlabs git repo, and
more specifically, here is the specification for Integer:
https://github.com/puppetlabs/puppet-specifications/blob/master/language/types_values_variables.md#integer-from-to
And here is Float;
https://github.com/puppetlabs/puppet-specifications/blob/master/language/types_values_variables.md#float-from-to
I logged PUP-3170 to track those.
The lengths of array, hash, and string are currently not specified.
We should create tickets for those as as well (or just expand on 3170,
because implementation wise it is pretty much the same thing (i.e. I
think the constraints should be checked by the type system).
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/lu55o3%24i59%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
