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