[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Action properties [WAS Action output?]
|
OK. I see your point (or points :-) ). How about the following:
Great! I was beginning to worry we'd lose ourselves in a discussion which
was moving all over the place. If we can agree on the rules for this top
thing, then the rest can follow (sometime later as needed).
1. The runtime properties are immutable so there's no way the chain of
actor execution can change them.
Yes, agree!
Every actor can *trust* that what they see is what's been defined by the
invoker of the perform command. This can be regarded as a good thing and
it's often very useful.
Example: I user -Dbuild.id=<some generated id> to give all actors an id
that they can use in order to brand their respective products.
Yes, agree!
scope has some problematic implications. We need a way to tie a property to
a specific action. An easy way to do that is perhaps to just use action
qualified property names.
Example: The component Z action 'rippage' needs a specific URL. So I
use -DZ#rippage!flmbrry.url=http://www.foo.org.
Precisely what I was imagining too - it makes for a horrible command line,
but that's a price to be paid.
Don't know if we'd be going to far but consider that you might want to
declare a prop to be sent to 'some components, but not all' - i.e. would it
be overkill to have the action qualified name be a regexp instead? There are
benefits to that, but also drawbacks - e.g., it makes the command line
potentially even more horrible, the user must understand regexps, and to
make parsing as easy and safe as possible, the 'global' props should all be
listed as '.*!foo=bar'...hmm. Other possibilities include different option
names (--define/-D vs --defineWithRe or whatever we'd come up with...hmm
again). We can skip this for the moment I think...
BTW, it was here I was imagining a 'pspec' file or something that would be
more easy to read, and also can be easily used by an 'UI action perform
initiator' to easily load various persisted 'perform command lines'. This
idea can also wait though...
I thereby state that an overlay with the property
flmbrry.url=http://www.foo.org must be added whenever the Z#rippage action
is executed (directly or implicitly). This overlay is explicit for such
invocations and cannot be seen by other actions. I will still be able to
use the global scope and write just -Dflmbrry.url=http://www.foo.org and
it's quite possible that it will yield the same result but there's some
risk involved when doing that.
Yup, all like I thought too.
Note that somewhere in all this is also where we started out - the idea of
having a --output that just mapped to a property...this has the same needs,
i.e. you must (for that particular property, I'd say that there is never
correct to send the same output root to >1 component) be able to steer one
setting for buckminster.output to one place for component X and to another
place for Y...We'd sort of need to duplicate similar ideas to that flag - or
skip that option flag entirely. Don't know what's best. Or if there's a
third, better option...
3. There is only one way to unintentionally 'confuse' an action with a
property setting and that is if you inadvertently override some property
that that action make use of. In order to prevent that from happening,
perhaps our actions should have a way to declare immutable properties?
Something like:
<property name="fee" value"fum" mutable="false"/>
The default is of course mutable="true"
It can't hurt...and actually can be very valuable...
Thinking about it gives me the idea that maybe we should consider to be
conservative and say that the default is 'mutable=false'. The rationale is
that since the usage of props in the actions becomes a very explicit part of
the contract, it stands to some reason that the designer of such things
specifically *have* to mark the ones that is mutable. Less chance for the
component/action designer to accidentally forget and then have someone else
make use of a prop that wasn't intended (and that the designer then *has* to
support...).
===
Finally, I was thinking about the perform command line: we have said that it
is (will be) correct to say this:
perform C1#A C2#B [...and so on]
I think it would be wise to code the execution so that it's illegal to
mention two actions that actually belong to the same dependency chain. I
admit that I can't see a great drawback to allowing it, but neither can I
see any benefit. It's more a hunch that it might come back and haunt us one
day, and it might give the user the incorrect expectation that they can
control/influence a dependency order...
?
ken1
