Kwalify validation
Ken Barber
requirements ... for example the bind zone configuration resource is
fairly complex in that it can have anywhere up to 40 different
attributes:
http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch06.html#zone_statement_grammar
Some of these attributes also require arrays and hashes to be passed
in puppet so I can easily convert them to bind grammar.
Now this is all very well and good - but I face the issue of trying to
validate these complex structures. In answer to this I created this
function:
Which allows validation using kwalify:
http://www.kuwata-lab.com/kwalify/ruby/users-guide.01.html#schema
This function monopolizes kwalify schema validation techniques - so I
can use Puppet hashes and arrays to create kwalify schemas to validate
my resource input. Some examples:
https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/kwalify-1.pp
https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/kwalify-2.pp
This is great in that I can now combine my validation into 1 data
structure and use that to validate ...
Now this in of itself is interesting but I started to think about the
wider case. What if I wanted to validate _every_ parameter in a class
or resource?
So I created this:
This converts all the params in a class or resource into a hash, and
goes looking for a separate schema file to use as validation. The idea
being, I can define a module_name/manifests/init.pp file with a class
in it, and a corresponding module_name/manifests/init.schema file for
its complex validation. This way you can create classes in the normal
layout structure, and have each class have a corresponding schema
file.
Some examples:
https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/validate_resource-1.pp
https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/validate_resource-1.schema
https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/validate_resource-2.pp
https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/validate_resource-2.schema
So now - I can allow complex structures to be passed, and have
validation in kwalify do most of the heavy lifting for validation ...
but also ... if someone was keen - they could use the kwalify schema
files - dynamically create a form in an ENC tool for parameterized
classes data entry purposes.
So the obvious debate to be made is weither this kind of complex
validation lives in the language or not ... but I do generally feel
that the current language support doesn't go deep enough to express
the data needed by a class and/or an ENC tool - kwalify comes a little
closer even if it isn't the correct implementation it certainly is
closer to the kind of information that needs to be expressed.
Anyway ... just want to put these ideas out there and see what people think.
ken.
Ken Barber
Which supports kwalify-like schemas to render forms using Javascript
(extra bits were added to support rendering). Here is a demo for an
address book editor for example:
http://robla.net/jsonwidget/example.php?sample=blankaddr&user=normal
While a bit rough - you can see it has capabilities to handle
structured data including nested elements like hashes and arrays. I
think it would be awesome to give users the power to just 'add a
class' in dashboard and be presented with a shiny form of this nature
to configure their app. The election example:
http://robla.net/jsonwidget/example.php?sample=normal&user=advanced
Shows off the use of context sensitive help which is derived from the
schema (click on help next to an attribute to see this).
And
Ken Barber
patch ... its not what one would call complete but I want to make sure
I'm going in the right direction:
https://github.com/kbarber/puppet/commit/74d32f3d8c565567faf23f90bbd828f8528539bb
So there are three sides to this ... the schema can now be obtained
using resource_type:
kbarber:puppet ken$ ~/Development/puppet/bin/puppet resource_type find
testclass{"name":"testclass","arguments":{"arg3":null,"arg4":null,"arg1":null,"arg2":null},"line":1,"schema":{"type":"map","mapping":{"arg3":{"required":true,"pattern":"/^\\d+$/","type":"str"},"arg4":{"type":"map","mapping":{"a":{"required":true,"pattern":"/^\\d+$/","type":"str"},"b":{"required":true,"pattern":"/^\\d+$/","type":"str"},"c":{"required":true,"pattern":"/^\\d+$/","type":"str"}}},"arg1":{"required":true,"type":"str"},"arg2":{"required":true,"type":"str"}}},"type":"hostclass","file":"/Users/ken/.puppet/modules/testclass/manifests/init.pp"}
kbarber:puppet ken$
If no schema is defined, you get back a schema derived from the
existing arguments:
kbarber:puppet ken$ ~/Development/puppet/bin/puppet resource_type find
testclass2
{"name":"testclass2","arguments":{"arg3":"\"asdf\"","arg1":null,"arg2":null},"line":1,"schema":{"type":"map","mapping":{"arg3":{"required":false,"default":"asdf","type":"str"},"arg1":{"required":true,"type":"str"},"arg2":{"required":true,"type":"str"}}},"type":"hostclass","file":"/Users/ken/.puppet/modules/testclass2/manifests/init.pp"}
kbarber:puppet ken$
And you now get rich validation - including things like regex pattern
validation:
kbarber:puppet ken$ ~/Development/puppet/bin/puppet apply
~/.puppet/manifests/site.pp
Failed kwalify schema validation:
[/arg4/a] 'd': not matched to pattern /^\d+$/. at
/Users/ken/.puppet/manifests/site.pp:10 on node kbarber.lan
kbarber:puppet ken$
I'm guess I'm just looking for direction. I want to see if people
think this kind of thing is a good idea and if my implementation is
correct. I have a number of concerns generally:
* A separate schema file while simple - feels like it might be the
wrong approach and potentially this should be in the language itself
somehow.
* I'm going to need to validate schema against the real argument list
in the class to make sure they don't mismatch.
* A schema/interface to anything can change - an ENC may need a quick
way of determining if there has been a change to understand if its
data needs to be re-validated. Versioning or hashes of the schema are
potential approaches.
* What if we want to use a different schema type in the future as
apposed to kwalify?
Thanks.
ken.
--
"Join us for PuppetConf, September 22nd and 23rd in Portland, OR:
http://bit.ly/puppetconfsig"
Dan Bode
So I managed to make some of this work in core. I've got a very basic
patch ... its not what one would call complete but I want to make sure
I'm going in the right direction:
https://github.com/kbarber/puppet/commit/74d32f3d8c565567faf23f90bbd828f8528539bb
added inline comments
So there are three sides to this ... the schema can now be obtained
using resource_type:
kbarber:puppet ken$ ~/Development/puppet/bin/puppet resource_type find
testclass{"name":"testclass","arguments":{"arg3":null,"arg4":null,"arg1":null,"arg2":null},"line":1,"schema":{"type":"map","mapping":{"arg3":{"required":true,"pattern":"/^\\d+$/","type":"str"},"arg4":{"type":"map","mapping":{"a":{"required":true,"pattern":"/^\\d+$/","type":"str"},"b":{"required":true,"pattern":"/^\\d+$/","type":"str"},"c":{"required":true,"pattern":"/^\\d+$/","type":"str"}}},"arg1":{"required":true,"type":"str"},"arg2":{"required":true,"type":"str"}}},"type":"hostclass","file":"/Users/ken/.puppet/modules/testclass/manifests/init.pp"}
kbarber:puppet ken$
If no schema is defined, you get back a schema derived from the
existing arguments:
kbarber:puppet ken$ ~/Development/puppet/bin/puppet resource_type find
testclass2
{"name":"testclass2","arguments":{"arg3":"\"asdf\"","arg1":null,"arg2":null},"line":1,"schema":{"type":"map","mapping":{"arg3":{"required":false,"default":"asdf","type":"str"},"arg1":{"required":true,"type":"str"},"arg2":{"required":true,"type":"str"}}},"type":"hostclass","file":"/Users/ken/.puppet/modules/testclass2/manifests/init.pp"}
kbarber:puppet ken$
I would prefer to not get back any schema if one is not specified. Not all users will want to create schemas, so this could wind up displaying unnecessary information.
And you now get rich validation - including things like regex pattern
validation:
kbarber:puppet ken$ ~/Development/puppet/bin/puppet apply
~/.puppet/manifests/site.pp
Failed kwalify schema validation:
[/arg4/a] 'd': not matched to pattern /^\d+$/. at
/Users/ken/.puppet/manifests/site.pp:10 on node kbarber.lan
kbarber:puppet ken$
I'm guess I'm just looking for direction. I want to see if people
think this kind of thing is a good idea and if my implementation is
correct. I have a number of concerns generally:
* A separate schema file while simple - feels like it might be the
wrong approach and potentially this should be in the language itself
somehow.
I think having the schema exist in a separate file is the right approach ( maybe I am just used to that b/c that is how it was done in Java). It makes it easy for users to view the resources in a manifest without having to simultaneously digest the schema. I think this lowers the barrier for entry for new users getting started.
* I'm going to need to validate schema against the real argument list
in the class to make sure they don't mismatch.
not sure what you mean
* A schema/interface to anything can change - an ENC may need a quick
way of determining if there has been a change to understand if its
data needs to be re-validated. Versioning or hashes of the schema are
potential approaches.
You could also create a yaml terminus and rebuild the cache when the schema or interface change (not sure exactly how this would work..)
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
--
"Join us for PuppetConf, September 22nd and 23rd in Portland, OR."
James Turnbull
> I would prefer to not get back any schema if one is not specified. Not
> all users will want to create schemas, so this could wind up displaying
> unnecessary information.
Whereas I think exactly the opposite. :) Not everyone is going to have
schemas and functionality that consumes this data shouldn't have to rely
on a supplied schema. Seems like a sensible default behavior to me.
> I think having the schema exist in a separate file is the right approach
> ( maybe I am just used to that b/c that is how it was done in Java). It
> makes it easy for users to view the resources in a manifest without
> having to simultaneously digest the schema. I think this lowers the
> barrier for entry for new users getting started.
As long as the schema is documented, located somewhere sensible and easy
to integrate and troubleshoot I think a separate file works.
Regards
James
--
James Turnbull
Puppet Labs
1-503-734-8571
Join us for PuppetConf <http://www.bit.ly/puppetconfsig>, September 22nd
and 23rd in Portland, Oregon, USA.
Ken Barber
>> in the class to make sure they don't mismatch.
>
> not sure what you mean
Just want to make sure what is specified in the schema aligns with
what parameters are defined in the class definition. For example -
someone may add a new argument to the class definition but not the
schema or vice-versa which would create a persistent validation error
when a user tries to use it.
Really this would involve comparing the schema with the arguments list
to make sure the top level names match - and the required/default
params also align.
Daniel Pittman
I think you nailed the point of complexity there: our current language
support doesn't do what we need, and kwalify is probably the best
choice for a validation language right now.
My major concern around this is that separate schema and class make it
hard for folks to keep them in sync; I know when I was doing Win32
development and we needed to maintain a separate "export" file next to
our code, the most common failure was to forget to update that.
I would ideally like to see this integrated as part of typing in the
language, so you would express constraints when you declare the
parameters to your class or define. That would give the assurance
that both were always consistent, and have only one place to view the
data.
I can't honestly say if I like this as an interim step on the way: it
gives us the capability now, and cheaply, which is pretty darn
awesome. We would really benefit from some uniform way to do this,
and it would let us test kwalify in the real world.
OTOH, it also means that we should support it to some degree as time
goes on. I would hate to let folks use it, then give them the short
stick when it comes to moving to whatever final mode we use.
On the gripping hand, it could be that language integration first
would show us this is not the right approach (though I can't imagine
how) and all...
So, yeah. Definitely not the wrong approach, and a good choice of
tools and an excellent balance of prototype cost vs results. I think
I will defer any final answer over to our UX master, Randall, about
the best way to try integrating this. Technically, though, it looks
pretty sound.
Daniel
I nearly said "kwalify is the least worst choice", because aside from
Rx (http://rx.codesimply.com/) it is one of the few validation
languages that was both complete enough and simple enough to use. It
still felt painful to use, though, in the real world.
--
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons
Randall Hansen
> I can't honestly say if I like this as an interim step on the way: it
> gives us the capability now, and cheaply, which is pretty darn
> awesome. We would really benefit from some uniform way to do this,
> and it would let us test kwalify in the real world.
I agree. Shippable solutions win over perfect designs.
However, I share Daniel's concerns about the schema being a separate
file, particularly if we're going to ship modules with this. For
someone new to the idea, there's no visible connection between a
`validate_resource()` call and a schema file. Inline comments might
help ameliorate this (e.g., "This function loads a .schema file in the
current directory"), but that's a fragile approach.
What if we included the schema in the manifest within the
`validate_resource()` call? This would make the connection more
explicit and avoid an extra file (and extra file /type/, which worries
me at least as much).
It would make manifests which use it larger, but I prefer ugly and
explicit communication over elegant and obfuscated[1].
Once we ship this we can work on a syntax to bring it into the
language and make the full schema obsolete. I imagine this wouldn't
land until Telly, so we have some time.
r
----
1. Not to imply that your current approach, Ken, is intentionally obfuscated :)
Ken Barber
> support doesn't do what we need, and kwalify is probably the best
> choice for a validation language right now.
>
> My major concern around this is that separate schema and class make it
> hard for folks to keep them in sync; I know when I was doing Win32
> development and we needed to maintain a separate "export" file next to
> our code, the most common failure was to forget to update that.
>
> I would ideally like to see this integrated as part of typing in the
> language, so you would express constraints when you declare the
> parameters to your class or define. That would give the assurance
> that both were always consistent, and have only one place to view the
> data.
Well one workaround for keeping the file in sync is to have code that
does a comparison on the top level between arguments and the schema
and throw an obvious error if they are not. At least then its caught
at runtime.
But I do feel your sentiments ... Java went through this same exercise
with CMP. In the end I believe they moved a lot of the logic to
annotations inside the Java code to avoid the double file exercise.
You could in theory transfer kwalify-like specification to the
language ... here is a quick hack for discussion:
class bind (
$options => {
type => map,
required => false,
mapping => {
"zone-statistics" => {
type => bool,
desc => "If true, the server will collect statistical data on
all zones"
},
"auth-nxdomain" => {
type => bool,
desc => "If true, then the AA bit is always set on NXDOMAIN
responses, even if the server is not actually authoritative."
},
"allow-query" => {
type => seq,
sequence => { type => str, desc => "Valid IP address",
pattern => '/^(\d+)\.(\d+)\.(\d+)\.(\d+)$/' },
desc => "Specifies which hosts are allowed to receive zone
transfers from the server",
},
}
},
$bind_user => {
type => str,
pattern => '/\w{1,15}/'
description => "OS user that bind runs as",
},
...
) {
# do something ...
}
Of course bind has hundreds of options ... so this would get large ...
but at least its all in one file.
> I nearly said "kwalify is the least worst choice", because aside from
> Rx (http://rx.codesimply.com/) it is one of the few validation
> languages that was both complete enough and simple enough to use. It
> still felt painful to use, though, in the real world.
Rx looks interesting - I haven't seen it before.
On another point ... I can see the need for handling obvious patterns
in a re-usable way like in the example above for IPv4. In kwalify this
would be done with merge mappings:
http://www.kuwata-lab.com/kwalify/ruby/users-guide.02.html#tips-merge
Which allows you to define a type, and use it later (and override
parts of it). Functionality much like this would be nice.
Ken Barber
> file, particularly if we're going to ship modules with this. For
> someone new to the idea, there's no visible connection between a
> `validate_resource()` call and a schema file. Inline comments might
> help ameliorate this (e.g., "This function loads a .schema file in the
> current directory"), but that's a fragile approach.
>
> What if we included the schema in the manifest within the
> `validate_resource()` call? This would make the connection more
> explicit and avoid an extra file (and extra file /type/, which worries
> me at least as much).
So using the function as apposed to the patch to core ... this is easy
enough to do. And I kind of agree if we stay with the function for
validation for now then it would make sense for visibility.
> Once we ship this we can work on a syntax to bring it into the
> language and make the full schema obsolete. I imagine this wouldn't
> land until Telly, so we have some time.
Indeed.
Daniel Pittman
>> I think you nailed the point of complexity there: our current language
>> support doesn't do what we need, and kwalify is probably the best
>> choice for a validation language right now.
>>
>> My major concern around this is that separate schema and class make it
>> hard for folks to keep them in sync; I know when I was doing Win32
>> development and we needed to maintain a separate "export" file next to
>> our code, the most common failure was to forget to update that.
>>
>> I would ideally like to see this integrated as part of typing in the
>> language, so you would express constraints when you declare the
>> parameters to your class or define. That would give the assurance
>> that both were always consistent, and have only one place to view the
>> data.
>
> Well one workaround for keeping the file in sync is to have code that
> does a comparison on the top level between arguments and the schema
> and throw an obvious error if they are not. At least then its caught
> at runtime.
>
> But I do feel your sentiments ... Java went through this same exercise
> with CMP. In the end I believe they moved a lot of the logic to
> annotations inside the Java code to avoid the double file exercise.
*nod* Multi-file systems seem to be long term troublesome.
> You could in theory transfer kwalify-like specification to the
> language ... here is a quick hack for discussion:
>
> class bind (
> $options => {
I imagined it being in the body, and calling a method, until we added
syntax, but either way would work. Mostly, I figure any solution lets
us figure out how well Kwalify is a match for our real-world needs.
> Of course bind has hundreds of options ... so this would get large ...
> but at least its all in one file.
Yeah. An external file would also be large; that bit doesn't change, really.
Hrm. Possibly using an explicitly scoped variable beside the class
declaration might be a way to get this into the language without so
much impedence mismatch in where you land the data?
$example::nested::class::options = {...}
class example::nested::class { ... }
>> I nearly said "kwalify is the least worst choice", because aside from
>> Rx (http://rx.codesimply.com/) it is one of the few validation
>> languages that was both complete enough and simple enough to use. It
>> still felt painful to use, though, in the real world.
>
> Rx looks interesting - I haven't seen it before.
>
> On another point ... I can see the need for handling obvious patterns
> in a re-usable way like in the example above for IPv4. In kwalify this
> would be done with merge mappings:
Yeah. My main concern would be that, like many of these things, Rx
looks to be a mostly dead language. On the plus side, there really
isn't a standard, so...
I guess we can always experiment with both and figure out what works.
Daniel
R.I.Pienaar
Have some experience with this problem and the mcollective DDL files.
Separate files *suck*
However I kept them separate because clients like web dashboard need
the DDL too and you would not always want to share the logic of the
agents with the frontend/clients/users. Think about secure environments
where how the agents work is sensitive information but the API they expose
is not.
If I had a full on DSL I'd probably have made effort to be able to
export the DDL file from the agents but I dont so 2 files were best I
could do.
If you can at all avoid separate files then do that.
--
R.I.Pienaar
Luke Kanies
I agree on not having separate files, and I think the rest is pretty easy - we already expose type/definition metadata over an API, so we'd just need to make sure we add this info to what we expose.
--
Kai's Example Dilemma:
A good analogy is like a diagonal frog.
---------------------------------------------------------------------
Luke Kanies | http://puppetlabs.com | http://about.me/lak
Join us in PDX for PuppetConf: http://bit.ly/puppetconfsig
Ken Barber
>> language ... here is a quick hack for discussion:
>>
>> class bind (
>> $options => {
>
> I imagined it being in the body, and calling a method, until we added
> syntax, but either way would work. Mostly, I figure any solution lets
> us figure out how well Kwalify is a match for our real-world needs.
Good points. This is a very non-intrusive way of experimenting with
kwalify I think. In that case we can drop the use of a file and have
the validate_resource() function take a kwalify schema (in the form of
a puppet hash) as a parameter.
> Hrm. Possibly using an explicitly scoped variable beside the class
> declaration might be a way to get this into the language without so
> much impedence mismatch in where you land the data?
>
> $example::nested::class::options = {...}
> class example::nested::class { ... }
Yeah - its important to make the schema available via REST from an
external ENC or hiera store editor ... if the data is not in a
known/obvious place that can be tapped from say an indirector of some
kind we lose some of the magic.
At the moment I've hacked on Luke's work with the resource_type API
which seemed like the most viable place to have the schema displayed.
I'm struggling to think of a way to extend this without changing core.
I mean - I could create a new indirector - but I'm not sure if its
possible to make an indirector as a plugin. Is this viable and/or a
good idea?
Daniel Pittman
>>> You could in theory transfer kwalify-like specification to the
>>> language ... here is a quick hack for discussion:
>>>
>>> class bind (
>>> $options => {
>>
>> I imagined it being in the body, and calling a method, until we added
>> syntax, but either way would work. Mostly, I figure any solution lets
>> us figure out how well Kwalify is a match for our real-world needs.
>
> Good points. This is a very non-intrusive way of experimenting with
> kwalify I think. In that case we can drop the use of a file and have
> the validate_resource() function take a kwalify schema (in the form of
> a puppet hash) as a parameter.
>
>> Hrm. Possibly using an explicitly scoped variable beside the class
>> declaration might be a way to get this into the language without so
>> much impedence mismatch in where you land the data?
>>
>> $example::nested::class::options = {...}
>> class example::nested::class { ... }
>
> Yeah - its important to make the schema available via REST from an
> external ENC or hiera store editor ... if the data is not in a
> known/obvious place that can be tapped from say an indirector of some
> kind we lose some of the magic.
I wonder if that is an immediate need, or if it could wait until we
started to merge this into the language proper? I guess, what I miss
right here is that while those are valuable uses of the data, they
don't seem to me on the critical path of testing Kwalify in the real
world and finding out how it works...
> At the moment I've hacked on Luke's work with the resource_type API
> which seemed like the most viable place to have the schema displayed.
> I'm struggling to think of a way to extend this without changing core.
This is the heart of why I look at it, and think that testing outside
the path of exposing the data would be good. Not for the long term,
just for right now, so we don't over-invest in data access before we
solve the problem of data format and integration.
API-wise, I would hope we could export the validation data in the same
place that we export the other class data (eg: not just that a
parameter exists, but type data for it) too.
daniel
Ken Barber
> started to merge this into the language proper? I guess, what I miss
> right here is that while those are valuable uses of the data, they
> don't seem to me on the critical path of testing Kwalify in the real
> world and finding out how it works...
So let me explain why I think this is important (at least from my
small perspective) - and I apologies if I'm re-iterating something
already known. One of the drivers behind this work is to allow rich
form entry for creation of parameterized classes in the dashboard.
This is an often-sought feature for the customers I speak to and I
think one of the reasons dashboard is not as often used for
ENC/configuration purposes (change auditing and roll-back being
another reason). Currently the specification we have is not rich
enough in my opinion to generate a form that includes things like:
complex data types (hashes, arrays), context sensitive help and client
side validation for the kind of users who _need_ to use dashboard.
Having said that though - providing a methodology for form generation
is only part of the problem, and really the ENC parts of dashboard
(whatever they end up looking like) need lots of work to make this
kind of magic happen anyway ... so its not important _now_. (but still
important to be mindful of :-).
I think for now modifying the existing function validate_resource()
(is this is a good name?) to take a kwalify schema and to validate the
current resource/class sounds like a good working approach. If no one
else has any problems with this - I'm happy to work towards that for
now.
Daniel Pittman
>> I wonder if that is an immediate need, or if it could wait until we
>> started to merge this into the language proper? I guess, what I miss
>> right here is that while those are valuable uses of the data, they
>> don't seem to me on the critical path of testing Kwalify in the real
>> world and finding out how it works...
>
> So let me explain why I think this is important (at least from my
> small perspective) - and I apologies if I'm re-iterating something
> already known. One of the drivers behind this work is to allow rich
> form entry for creation of parameterized classes in the dashboard.
*nod*
> This is an often-sought feature for the customers I speak to and I
> think one of the reasons dashboard is not as often used for
> ENC/configuration purposes (change auditing and roll-back being
> another reason). Currently the specification we have is not rich
> enough in my opinion to generate a form that includes things like:
> complex data types (hashes, arrays), context sensitive help and client
> side validation for the kind of users who _need_ to use dashboard.
Yeah. So, long term I think a method for providing rich annotations
of things in the Puppet language is a solid goal, and that this
validation is part of the process of getting there. Ideally, it would
be good to have a unified design, but failing that at least knowing
the tools are solid is great.
So, I think it is extremely valuable to expose this, and don't get me
wrong. I just think there is value in establishing that Kwalify is
useful alone of that.
> Having said that though - providing a methodology for form generation
> is only part of the problem, and really the ENC parts of dashboard
> (whatever they end up looking like) need lots of work to make this
> kind of magic happen anyway ... so its not important _now_. (but still
> important to be mindful of :-).
>
> I think for now modifying the existing function validate_resource()
> (is this is a good name?) to take a kwalify schema and to validate the
> current resource/class sounds like a good working approach. If no one
> else has any problems with this - I'm happy to work towards that for
> now.
Awesome. I totally agree with your overall position, though.
Daniel