Subject: Re: output port groups WAS(Re: Revised LFB input/output text

From: "Deleganes, Ellen M" <[email-masked]>
Date: Wed, 12 May 2004 09:35:44 -0700

I should have been clearer in the first paragraph. In the last sentence
what I really meant to say is: I don't believe the FE model intends to
disallow an implementation from specifying multiple singleton outputs. I
view the output group as a convenient concept or notation, to describe
multiple outputs with similar characteristics. Whether an array is used
to specify the members of the group or individual names are given to
each singleton output is completely up to the implementer. It doesn't
take that much imagination to see that individual outputs within an
output group could be specified as individual units. It is slightly more
difficult to determine which outputs have enough in common to put into a
group, and the model team is attempting to describe when it is
appropriate to group outputs.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Friday, May 07, 2004 6:41 AM
To: [email-masked]
Subject: Re: output port groups WAS(Re: Revised LFB input/output text

On Thu, 2004-05-06 at 11:47, Deleganes, Ellen M wrote:

> <EMD> An output group can be decomposed into multiple singleton
outputs
> in an implementation. The output groups are a convenient modeling
> concept to group logically similar outputs from a single LFB together.
> An implementation could either describe the outputs using a group
> notation or as individual outputs if it desires, I don't see why the
FE
> model disallows the multiple singleton output method.
> </EMD>

[..]

> <EMD> I can't think of a specific example offhand either, but someone
> might. Setting an artificial limit when it doesn't simplify anything
> doesn't make sense either if there is a possibility where someone
might
> need more than two groups.
> </EMD>
>

Ok, heres what you need to do so we can move on (I have about a million
other comments on the model draft. I am also eagerly awaiting a response
on the metadata from moons ago to be responded to).

1)I honestly dont think "redirector" is the right noun. If you insist
on using it, please explain the current common usage of the term and the
generalization of it. Probably something with the word "mux" in it would
be useful. I think another term that needs to be scrubbed/defined
is the "port" into/outof the LFB

2)If you insist on using "output groups" and "ports" (both of which i
dont like) then you need to strengthen your text in a big way.
I apologize for bringing this up again: As an example since you are
struggling to find an example for more than two port groups, you clearly
have no need for more than two - i would like to point out (again!) that
you dont need more than one, and that if you dont need more than one,
then you dont need the term "group". I should add, however, i am willing
to live with for a middle ground good text explaining these details.
Sorry, cant come up with non-biased text; so i will leave that to you
hoping you understand my view.

> <EMD> The model document is intended to allow flexibility in
> implementations - this was one of the explicit requirements on the
model
> document. It is possible that no implementation will support all of
the
> flexibility and extensibility spelled out by the model document.
> </EMD>

Its clearly not flexible enough if i am trying hard to fit myself within
it;-> I think the model is fine to capture all sorts of ideas, but the
basics must be right. The outputs and inputs are basic.[1]

cheers,
jamal

[1]Theres a lot of stuff i am throwing out or ignoring because the model
is trying to cover everything under the sun.
Example i wouldnt give a rats ass about inheritance of LFBs. I am sure
someone with a product or trying to get a phd thesis would disagree. I
am just being practical.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 14 May 2004 10:15:53 -0400

> appropriate to group outputs.

The logic doesnt make sense. Lets see:
You create something called a output group and then by induction logic
create even more extensions to it. Somehow you overlooked if there was a
requirement for it to begin with? Why is this an afterthought?

The problem is i actually think you have a reason for it - which maybe
implementation specific. I wish you would come out and describe what it
is because you are not making any progress convincing me (Neither I
convincing you).

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 May 2004 17:23:14 -0400

Would it sufficiently address your concerns if in the definition of the
rules for LFB class definition (the schema for the LFB class XML) for
output ports from an LFB, the definition allowed any number of named
singleton output ports, and only allowed up to one named output port group?
Would you like a similar restriction on the definition for the input side?

If that would leave you significantly more comfortable, I am willing to
accept that.

Yours,
Joel M. Halpern

PS: Just to be clear, I do not think that the protocol or the LFB class
schema will be more complex if we allow multiple groups.  Since the LFB
class definition will only be more complex it actually uses multiple output
groups, I would prefer that the schema allowed for that.  However, since it
seems likely that LFB classes which should use multiple groups are rare, I
can live without the capability.