So, having gone down this rabiit hole, let me explain my primary
objection to this feature.
The idea of the feature is that the I2RS client does not ahve to set up
these templates, but simply uses them. And that by having different
templates on different devices it can get the "right result" in
different places.
Which means that the client does not actually know what its request is
going to do. the template may or may not actually do what it wants,
because the client did not establish the template.
For CLI operation, this kind of template operation seems very useful.
For automated operation, I am concerned by the loss of information at
the client.
Yours,
Joel
On 5/14/14, 12:33 PM, Jeffrey Haas wrote:
On Wed, May 14, 2014 at 12:28:44PM -0400, Joel M. Halpern wrote:
I wish it were just an implementation issue.
If we are going to support this in the protocol then:
1) We need a mechanism explicitly in the protocol to say "use this
template".
2) We need to include templates in the set of things we model.
+1
One of the cases in the pending architecture doc refresh (don't recall if
it's in the existing version) is effectively "copy constructor" behavior for
templates.
If we had the equivalent of configured state that was scoped to not commit
(yes, obviously ugly but potentially another one of those side data stores
we have been talking about), then you have identified objects that are
"committed" somewhere (not impacting running state) that can be referenced
for such a copy constructor. Effectively, a form of template.
-- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
