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 11:13 AM, Joel Halpern Direct
<[e-mail]> wrote:
> 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.
>

It is awkward because it is "parallel" and because I
will have to go looking for your document.
What i am proposing is discoverability. I can query the FE to tell
me about a class components, their types etc.

cheers,
jamal

> 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
>>>>
>>>
>