Re: [buckminster-dev] How to improve mapping rules in the Aggregator

[Thomas Hallgren <thomas@xxxxxxx>]

On 2009-12-07 22:00, Filip Hrbek wrote:
> I think that a proxy is expected to be resolved into a uniquely defined
> object.
> Upon a request to one of object's properties, if the object is an
> unresolved proxy reference,
> it is lazily resolved and the properties are initialized upon successful
> resolution.
>
Yes. That sounds like more or less exactly what we want.

> If the resolution is not successful, the properties are not initialized.
> However,
> we need them for the presentation layer. Currently we cheat in that case
> - we parse the
> proxy URI using regexp and create fake properties from it. That's
> something I don't
> like at all.
>
Because?

> Instead, I would prefer specifying all the request properties in the
> request instance (i.e. current MappedUnit).

You wanted to avoid redundancy. This sounds just like that.

> The presentation of the request would not
> have to analyze whether
> the request is resolvable or not until we want to show status or mapping
> hints to the user.
>
Is that a good thing? I would prefer if all markers etc. were in place from the start so that I can click through my 
problem view and perhaps execute suggested fixes.


> When the aggregation build is run, the mapping requests can be easily
> converted into the
> "all.contributed.content" feature's required capabilities (possibly with
> version ranges,
> not only concrete versions), without resolving the requests one by one.
>
> I still can't see any advantage of using EMF proxy mechanism here.
>
The advantage is that normal model navigation applies. The engine could do exactly what it does today with no changes.

I suspect that we will run into a whole slew of problems if we remove the EMF dependency. A simple change in how the 
proxy is resolved sounds a lot simpler and safer.

- thomas