You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/08/10 18:02:01 UTC
Policy intents and policySets on bindings and implementations
I noticed that bindings and implementations now have:
- intents
- policySets
and
- computedIntents
- computedPolicySets
How about simplifying this a bit and doing what we've done in
CompositeBuilder with all other similar cases like bindings, property
configuration etc.
- we read intents
- we compute/combine/override intents declared at different levels
- eventually the intents field contains the effective (computed) intents
With bindings on references for example we don't have bindings and
computedBindings...
This will make the model simpler, and will also avoid confusion when
people use the model, like: hmm I'm looking at Binding, which intent
field should I use? intents or computedIntents? should I add to both?
which one should I get the intents from? if I add to one does the other
reflect my changes? etc. :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy intents and policySets on bindings and implementations
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Venkata Krishnan wrote:
> Hi Sebastien,
>
> Yes, this was what I intended to do initially. But got a bit
> concerned about losing the original state of the model after build
> time. I was thinking of a Admin or Mgmt function that might display
> the original configurations before thing got built i.e. computed or
> aggregated. For this I thought its best to have information that was
> originially loaded preserved.
>
> The 'ComputedIntents' and 'ComputedPolicies' will only emerge during
> the build time. I could not figure out a better place to hold this
> information than the model itself.
>
> Well, that's just for explaining the thoughts behind that
> implementation. I am open to cutting this out :).
>
> Independent of this change, could you please help me get some clarity
> on how we could retrieve the original configurations. Thanks.
>
> - Venkat
>
If you want to implement an administration tool that shows the original
composites, components, services, references, implementations,
bindings... and policies then just don't call CompositeBuilder.build() :)
Administration tools, wizards, and editors should use the original
models loaded from the development artifacts. CompositeBuilder.build()
refactors and transforms the original assembly model so much (to make it
easier to process at runtime) than preserving only the original policies
wouldn't help anyway.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy intents and policySets on bindings and implementations
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien,
Yes, this was what I intended to do initially. But got a bit
concerned about losing the original state of the model after build
time. I was thinking of a Admin or Mgmt function that might display
the original configurations before thing got built i.e. computed or
aggregated. For this I thought its best to have information that was
originially loaded preserved.
The 'ComputedIntents' and 'ComputedPolicies' will only emerge during
the build time. I could not figure out a better place to hold this
information than the model itself.
Well, that's just for explaining the thoughts behind that
implementation. I am open to cutting this out :).
Independent of this change, could you please help me get some clarity
on how we could retrieve the original configurations. Thanks.
- Venkat
On 8/10/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> I noticed that bindings and implementations now have:
> - intents
> - policySets
>
> and
>
> - computedIntents
> - computedPolicySets
>
> How about simplifying this a bit and doing what we've done in
> CompositeBuilder with all other similar cases like bindings, property
> configuration etc.
> - we read intents
> - we compute/combine/override intents declared at different levels
> - eventually the intents field contains the effective (computed) intents
>
> With bindings on references for example we don't have bindings and
> computedBindings...
>
> This will make the model simpler, and will also avoid confusion when
> people use the model, like: hmm I'm looking at Binding, which intent
> field should I use? intents or computedIntents? should I add to both?
> which one should I get the intents from? if I add to one does the other
> reflect my changes? etc. :)
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org