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

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

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.

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
>