Subject: more updates to path-data text

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 3 Feb 2005 22:40:14 -0500

More updates. Joel, Look at examples 6-9; there may be some lack
of clarity still.

$Log: data_path2.txt,v $
Revision 1.9  2005/02/03 22:35:49  hadi
rearranged text and redid the use cases to match
changed BNF

Revision 1.8  2005/02/02 20:19:10  hadi
incorporating Joels text and Weimings input

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Feb 2005 23:25:22 -0500

I think the second response in example 6 is the correct one.  The first 
response would be a response to getting all of table2, when it only had a 
row at index 0 and nothing else.
The difference is that if one SETs the table with the first response, one 
will throw away all the other rows.  If one SETs the table with the second 
response, one SETs the correct entry.

Of the three alternatives listed in example 8, the first and second are 
both correct.  I actually prefer the second, but I believe the protocol 
should allow both.  (As discussed above, the third alternative would mean 
"reduce the entire table to a single row at index 5, with the specified 
vale."  While occasionally useful, that is not what was intended.

I am not sure if 9 "needs" a NEEDIDX flag, but I would like it to have one.

For examples 4 and 7, what you describe seems correct.  I was wondering if 
as  a tradeoff of clarity for slightly reduced efficiency we should use 6 
DATARAW TLVs?

Redundancy warning:
    As we have discussed, but not resolved, I believe example 11 will 
return exactly 1 entry, and the text for example 12 describes something 
that can not happen.  (I think that the message shown for example 12 
actually references the 10 elements starting at index 10 of the inner table 
with ID4 inside table2.  Debating how to represent what the text describes 
is only useful if we decide that keys are not unique and therefore the 
described case can occur.)

Thanks,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 4 Feb 2005 09:04:21 -0500

> response, one SETs the correct entry.

This makes sense; fixed.

> vale."  While occasionally useful, that is not what was intended.

I left those two for illustration purposes but deleted the one.

> I am not sure if 9 "needs" a NEEDIDX flag, but I would like it to have one.

Hrm, you are right - and its actually a point i made in an earlier mail ;->
Too tired when i was typing that text in. I think the NEEDIDX would help
give a quick hint .. but is not totaly necessary. Add it?
 
> as  a tradeoff of clarity for slightly reduced efficiency we should use 6 

While 6 DATARAWs would be valid, isnt the following both legit and efficient 
(in packing and parsing effort)?

Path-data TLV:
        IDCount = 1, IDs=4
        DATARAW TLV: L = XXX, V=
                0,j1value,j2value                
                1,j1value,j2value               
 		2,j1value,j2value
                3,j1value,j2value
                4,j1value,j2value
		5,j1value,j2value

L will tell you how many rows you have packed.

> return exactly 1 entry, 

I didnt follow; there was a small mistake - it should read:

------
11) get _all_ row entries from table4 where j1=100

OPER = GET
        Path-data TLV:
                flags = F_SELKEY  IDCount = 1, IDs=6
                KEYINFO TLV = {KEYID =1 KEY_DATA=100}

Result:
Path-data TLV:
        IDCount = 1, IDs=6
        DATARAW TLV, Length = XXXX
                index, j1value,j2value, j3value, j4value
                index, j1value,j2value, j3value, j4value
                index, j1value,j2value, j3value, j4value
-------

note j1 KEYID 1 for table 4. i used j1 and j2 in two tables - may have created
confusion.

> and the text for example 12 describes something 
> with ID4 inside table2.

;-> Agreed since we show start and end of TLVs visually.

> Debating how to represent what the text describes 

Would representing the text as below serve better to express the need
to use the two selectors to zone on the data of interest?

-------
12) delete  first 10 row entries with KEY match (j1=100, j2=200)
 in table 2, starting at index 10.

OPER = DEL
        Path-data TLV:
                flags = F_SELKEY  IDCount = 1, IDs=4
                KEYINFO TLV:  {KEYID =1 KEY_DATA=100,200}
        Path-data TLV:
                flags = F_SELBLK  IDCount = 1, IDs=4
                BLK_CNT_INDEX TLV
                        start = 10
                        count = 10

Result:
This assumes we have asked for the full results back in the main header.
Assuming we deleted 3 at indeces 11, 13, and 18.

Path-data TLV:
        IDCount = 1, IDs=4
        DATARAW TLV, Length = XXXX
                11,j1value,j2value
                13,j1value,j2value
                18,j1value,j2value

TBD:  What to do when we request the next 10 entries but theres
only 5? What about when the highest index available is 5?
Need to enumerate all possible error paths

--------

cheers,
jamal