| Advising Build Units - "internal advice" [message #487378] |
Tue, 22 September 2009 23:24  |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Hi,
In b3 we want to support advice on build units using two different
mechanisms:
- advice provided inside a build unit (e.g. the way Buckminster CSPEX works)
- advice externally injected (or decoration if you prefer that term).
This post is about the first form - advise provided inside the build unit.
In Buckminster, the advice is supported directly by the various readers.
In b3, I think we should support buckminster's CSPEX as well as other
mechanisms to provide advice (I am sure we are going to get a great
xtext based way to express advice for instance).
I have been thinking how this could be supported while keeping meta data
translators free of this concern. The current model selects a meta data
translator based on a resolver, and the namespace of the requested
component. It seems natural to add a second extension mechanism that
kicks in as a second step.
A Buckminster advisor could operate on any IResolver that implements
IEFSBasedAccess looking for the file /buckminster.cspex for instance.
Basically, it is a "chained" resolver that gets a resolution as
additional input.
However, since all advice providers should be given a chance, there is a
need to iterate - perhaps letting the first win (as two forms of
internal advice at the same time (i.e. both a buckminster.cspex, and
some newer form of adivce) seems a bit odd.
Alternativly, all meta data translators are given a list of files /
probes that indiciate the precense of advice - it would then be the meta
data translators job to detect if the advice is present - and then hand
over to the advisor. This would enable a non EFS based meta data
translator to also use internal advice. Apart from that benefit, the
solution is just less clean IMO.
Thoughts?
Handling injected advice is a topic on its own.
- henrik
|
|
|
| Re: Advising Build Units - "internal advice" [message #487399 is a reply to message #487378] |
Wed, 23 September 2009 06:05  |
|
On 09/23/2009 01:24 AM, Henrik Lindberg wrote:
> ...
> However, since all advice providers should be given a chance, there is a
> need to iterate - perhaps letting the first win (as two forms of
> internal advice at the same time (i.e. both a buckminster.cspex, and
> some newer form of adivce) seems a bit odd.
>
Not sure I agree with that. If several advices are present then they should be applied in succession. There must be some
order. Perhaps I install some new advice capability into my build environment that automatically advices some aspect of
all my BuildUnit's. Why would that inhibit the use of other advices on the same aspect? I'd like to see it more like an
onion where each advice adds its own layer.
A BuildUnit should be a black box to its surroundings. How it came into existence should not affect where advices and or
cannot be applied.
> Alternativly, all meta data translators are given a list of files /
> probes that indiciate the precense of advice - it would then be the meta
> data translators job to detect if the advice is present - and then hand
> over to the advisor. This would enable a non EFS based meta data
> translator to also use internal advice. Apart from that benefit, the
> solution is just less clean IMO.
>
> Thoughts?
>
Isn't the advice mechanism very similar to the property mechanism? I.e. wouldn't a closure be a good place to store
advices that should be applied downstream?
- thomas
|
|
|
| Re: Advising Build Units - "internal advice" [message #487441 is a reply to message #487399] |
Wed, 23 September 2009 09:38 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Closures are not used until evaluation starts, so something else is
needed to define the order between the advisors in the general case.
It could be an order that is determined by the configuration (e.g. osgi
service priority) which enables a user to configure the order.
One could also argue that the order does not matter if the advice is
without conflict. The issue then becomes what to do when there is
conflicting advice. I can see this happen a lot actually. Build units
from the past were extended, and the extension ended up being part of
some other translator/advisor in the next release. What should happen in
this case?
Actually, I wonder if not all advice should be seen as injected (even if
specified inside build units). Then it becomes possible to make
statements about order and conflicts. I am going to explore this as a
solution...
- henrik
Thomas Hallgren wrote:
> On 09/23/2009 01:24 AM, Henrik Lindberg wrote:
>> ...
>> However, since all advice providers should be given a chance, there is a
>> need to iterate - perhaps letting the first win (as two forms of
>> internal advice at the same time (i.e. both a buckminster.cspex, and
>> some newer form of adivce) seems a bit odd.
>>
> Not sure I agree with that. If several advices are present then they
> should be applied in succession. There must be some order. Perhaps I
> install some new advice capability into my build environment that
> automatically advices some aspect of all my BuildUnit's. Why would that
> inhibit the use of other advices on the same aspect? I'd like to see it
> more like an onion where each advice adds its own layer.
>
> A BuildUnit should be a black box to its surroundings. How it came into
> existence should not affect where advices and or cannot be applied.
>
>> Alternativly, all meta data translators are given a list of files /
>> probes that indiciate the precense of advice - it would then be the meta
>> data translators job to detect if the advice is present - and then hand
>> over to the advisor. This would enable a non EFS based meta data
>> translator to also use internal advice. Apart from that benefit, the
>> solution is just less clean IMO.
>>
>> Thoughts?
>>
> Isn't the advice mechanism very similar to the property mechanism? I.e.
> wouldn't a closure be a good place to store advices that should be
> applied downstream?
>
> - thomas
|
|
|
| Re: Advising Build Units - "internal advice" [message #577856 is a reply to message #487378] |
Wed, 23 September 2009 06:05 |
|
On 09/23/2009 01:24 AM, Henrik Lindberg wrote:
> ...
> However, since all advice providers should be given a chance, there is a
> need to iterate - perhaps letting the first win (as two forms of
> internal advice at the same time (i.e. both a buckminster.cspex, and
> some newer form of adivce) seems a bit odd.
>
Not sure I agree with that. If several advices are present then they should be applied in succession. There must be some
order. Perhaps I install some new advice capability into my build environment that automatically advices some aspect of
all my BuildUnit's. Why would that inhibit the use of other advices on the same aspect? I'd like to see it more like an
onion where each advice adds its own layer.
A BuildUnit should be a black box to its surroundings. How it came into existence should not affect where advices and or
cannot be applied.
> Alternativly, all meta data translators are given a list of files /
> probes that indiciate the precense of advice - it would then be the meta
> data translators job to detect if the advice is present - and then hand
> over to the advisor. This would enable a non EFS based meta data
> translator to also use internal advice. Apart from that benefit, the
> solution is just less clean IMO.
>
> Thoughts?
>
Isn't the advice mechanism very similar to the property mechanism? I.e. wouldn't a closure be a good place to store
advices that should be applied downstream?
- thomas
|
|
|
| Re: Advising Build Units - "internal advice" [message #577869 is a reply to message #487399] |
Wed, 23 September 2009 09:38 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Closures are not used until evaluation starts, so something else is
needed to define the order between the advisors in the general case.
It could be an order that is determined by the configuration (e.g. osgi
service priority) which enables a user to configure the order.
One could also argue that the order does not matter if the advice is
without conflict. The issue then becomes what to do when there is
conflicting advice. I can see this happen a lot actually. Build units
from the past were extended, and the extension ended up being part of
some other translator/advisor in the next release. What should happen in
this case?
Actually, I wonder if not all advice should be seen as injected (even if
specified inside build units). Then it becomes possible to make
statements about order and conflicts. I am going to explore this as a
solution...
- henrik
Thomas Hallgren wrote:
> On 09/23/2009 01:24 AM, Henrik Lindberg wrote:
>> ...
>> However, since all advice providers should be given a chance, there is a
>> need to iterate - perhaps letting the first win (as two forms of
>> internal advice at the same time (i.e. both a buckminster.cspex, and
>> some newer form of adivce) seems a bit odd.
>>
> Not sure I agree with that. If several advices are present then they
> should be applied in succession. There must be some order. Perhaps I
> install some new advice capability into my build environment that
> automatically advices some aspect of all my BuildUnit's. Why would that
> inhibit the use of other advices on the same aspect? I'd like to see it
> more like an onion where each advice adds its own layer.
>
> A BuildUnit should be a black box to its surroundings. How it came into
> existence should not affect where advices and or cannot be applied.
>
>> Alternativly, all meta data translators are given a list of files /
>> probes that indiciate the precense of advice - it would then be the meta
>> data translators job to detect if the advice is present - and then hand
>> over to the advisor. This would enable a non EFS based meta data
>> translator to also use internal advice. Apart from that benefit, the
>> solution is just less clean IMO.
>>
>> Thoughts?
>>
> Isn't the advice mechanism very similar to the property mechanism? I.e.
> wouldn't a closure be a good place to store advices that should be
> applied downstream?
>
> - thomas
|
|
|
Powered by
FUDForum. Page generated in 0.03958 seconds
] 
Search
Help
Register
Login
Home
