[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] How to improve mapping rules in the Aggregator
|
On 2009-12-08 01:30, Filip Hrbek wrote:
>> Problem number one:
>> Backward compatibility. My suggested approach would have a proxy
>> resolver that acts on a URI. This resolver can easily detect if the
>> URI is the old style or a new style. The model is essentially
>> unchanged. If we instead change the model and remove the dependency,
>> the backward compatibility layer becomes more complex.
>
> Does it mean that we must keep the original model forever? No!
Do we want breaking changes in the model that are not really justified? No!
> We have two options:
> a) provide a conversion tool
> b) implement automatic conversion attempt on unsuccessful opening
>
c) use an improved proxy resolution scheme
> It's always better to clean up the model than to keep backward capability
> together with problems.
I would agree to that if I saw the problems. As it stands now, I don't. So can you please show me what the problem is?
> Using option b), current users won't notice that anything has changed.
>
>>
>> Problem number two:
>> The EMF model is built on dependencies, containment, reverse
>> dependencies, etc. If we simply remove the dependency, all of that is
>> gone and we need to maintain notifications etc. ourselves. All future
>> code (b3 for instance) that wants to use the model must cater for our
>> special "almost a dependency but in fact not" solution.
>>
>
> Not sure I follow - could you provide a concrete example of what we
> are breaking and what problems you can see there?
What if someone would like to use dynamic EMF to navigate the model? I know for sure that b3 for instance, will do just
that.
> We are talking about requests what to map, not about concrete IUs to map.
>
I think this is where our view differ. I see the link between the MappedUnit and the actual IU as something fairly
concrete. You either have a problem of some kind, or a resolved proxy.
> So I think that the proposed solution is much much cleaner and I would
> expect much less problems than now.
>
What problems would that be? The only thing you've mentioned so far is that there's a problem since the URI contains
redundant data. We agree that the redundant part should be removed. So what's left?
- thomas
