Re: [forces] Avoiding need to issue a draft every time WAS(Re: FEO events

[Jamal Hadi Salim <[e-mail]>]

On Thu, Nov 20, 2014 at 10:52 AM, Joel Halpern Direct
<[e-mail]> wrote:
> Subclassing is precisely designed to provide augmentation.
> You can also do associated classes / instances (which is what folks usually
> get with augmentation) but I prefer subclassing.
>

Sub classing requires a new class identity.

If i defined a port LFB and then inherited into
a gre LFB it makes sense because I need most of the fields
port has to offer; i can override some of them and i
can augment.

But all i wanted was to add a new field to gre meaningful
to gre, it doesnt make sense i go and subclass that.
My initial thinking (before Julian commented) was we change
the version. The scaling problem i am describing here is
this idea of adding new fields in self-contained LFB classes
is the way of life in open source. And people survive fine without
versioning.

cheers,
jamal

> Yours,
> Joel
>
> On 11/20/14, 10:50 AM, Jamal Hadi Salim wrote:
>>
>> On Thu, Nov 20, 2014 at 10:32 AM, Joel M. Halpern <[e-mail]>
>> wrote:
>>>
>>> I think that there are several issues combined here.
>>>
>>> We already have mechanisms so that anyone can define LFBs.  And that
>>> includes new subclasses of existing LFBs.  Note that he information as to
>>> what LFB classes and subclasses an FE supports is easily discoverable,
>>> by design.
>>>
>>
>> That part works well.
>>
>> Lets put FEPO/FEO to the side for the sake of discussion.
>> Say i defined a port LFB and I publish it and it ends up being RFC.
>> And then two months down the road i would like to add a new
>> component - the process requires me to publish a new document
>> and go through the same publication. That is manageable if the
>> churn stops at some point. It never stops in open source.
>> So the idea that i have to create a document and go through a standards
>> process doesnt scale.
>>
>>> There is the question of whether event mechanism should be more easily
>>> extended than a new subclass.  I have trouble seeing how we could
>>> do that,
>>> since in many instances it will require different code in the FE to
>>> generate
>>> new events.
>>>
>>
>> I think the sub-classing issue also works well. What i am refering to
>> is more class "augmentation" than it is sub-classing.
>>
>>> Then there is the question of changes to the FEO (or FEPO).  For
>>> itneroperability, those have to be very stable.  In this case, for
>>> example,
>>> if your CE needs those events, you can only work with FEs that have been
>>> upgraded to generate those events from the FEO.   If we allow random
>>> changes
>>> to the FEO, the probability of interoperability between independent
>>> implementations is very low.  So while I am sympathetic, I am reluctant
>>> to
>>> go down a path the makes interoperability harder.
>>>
>>
>> We can make an exception for FEPO/FEO. But think of other
>> classes which merely require a new component augmented
>> (not subclassing).
>>
>> cheers,
>> jamal
>>
>