Subject: Ambiguity in BLOCK semantics-some qs?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 14 Feb 2005 18:38:37 -0800

Hi Joel, Jamal,

I have a few questions in this regard which may or may be not directly
related to the block semantics...I hope you wont mind providing me with
the rationale...

* Why do we need to support nested PATH-DATA in the grammar?
i.e. DATA := [DATARAW] | <PATH-DATA>+ instead of DATA := [DATARAW]
I believe we could support all the use cases using the latter, in a
simpler way.

* Why can be use the DATARAW itself to support Block operations?
i.e. 		DATARAW TLV: L = XXX, V=
			0, j1value, j2value
			1, j1value, j2value
			2, j1value, j2value
			3, j1value, j2value
			4, j1value, j2value
			5, j1value, j2value
We can do this to set the entire table, why not use the DATARAW directly
to set a block of table entries? I think Joel had given me some reason
for this on our conference call, but I missed it.

I appologize in advance if I am asking something that is already
discussed.
If you could point me to the relevant emails, in case this was discussed
it would be very helpful.

Thanks a lot,
Hormuzd

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Feb 2005 22:49:30 -0500

One the nested PATH-DATA, this was an efficiency mechanism.  As you say, 
everything it can do can be done without it.
However, there are two important factors:
1) It is simple, well defined, easy to describe, and I think reasonably 
easy to implement.
2) It covers a case that is clearly likely, namely setting multiple things 
in the same portion of the LFB.
I think it is a good efficiency tradeoff.

My view on the DATARAW with indices is that it is for use when we are 
representing the whole table.  It seems to me that one important use case 
for setting into a table is where we are resetting the table, creating the 
new entries and throwing away whatever was in the table before (just as 
setting a variable discards the old value.)  If we used indices in a 
DATARAW for a table to enable selective block operations, then we would 
need some other way to handle setting the "whole" table.
And it should be pointed out that this would still leave many of reasonable 
the uses of BLK unsupported.
I would not be surprised if once we complete the protocol and get some 
implementation and ueage experience, we don't decide on some form of 
BLK.  That is why we are being careful to make sure it is easy to add later.

Yours,
Joel