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

[Joel Halpern Direct <[e-mail]>]

You can always create parallel classes (gre-augmenting-class1) which are 
used just to hold extra configuration without being in the data path. 
Yes, it is a bit awkward as you can have the back-pointer but no 
forward-pointer.  But it works.  And it requires no RFC.  Just use the 
FCFS portion of the registry.

Yours,
Joel

On 11/20/14, 10:58 AM, Jamal Hadi Salim wrote:
> 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
>>>
>>