[Forces-protocol] Data Encoding

["Weiming Wang" <[e-mail]>]

Jamal,  Joel as well,

Good, I'l try to follow the example in the doc. I'm just trying to raise some
question in the line actually trying to show my view further.

To summarize, I strongly believe the Data field should allow IDs other than pure
values. I think in the examples Jamal also has shown some cases where Data are
not pure values (including index, field ids).

Regarding using Data encoding without IDs,  I really have a feeling that it is
more dangerous than with IDs. Note one bit error produced by programmer (e.g.,
mistaken one u32 to u64 and another u64 to 32) will result in the total failure
for the whole Data and the error is hard to be debugged (no IDs to verify it).
One more question is the appearing sequence also become important with this
approach, which makes the FE model schema sequence sensetive. This is really
inconvenient.

I'm trying to add Steve and Zsolt in the list (but seems Steve's server always
takes my post as spam:( .  ).

Cheers,
Weiming
---------------------
OPER_TLV : = <PATH-DATA>
PATH-DATA := flags IDcount <IDs> [BLOCK_OR_KEY_NOTATION] [DATA]
[Weiming]Why don't we just set the PATH as a TLV?

-> IDs := a series of 32bit IDs (whose size is given by IDcount) defining the
path.
[Weiming] Obviously, we need a flag to indicate the ID being index(subscript) or
field ID as
    ID:= flag(1bit)  Index(31bit) | fieldID(31bit)
    flag:=0(fieldID) | 1(index)
[/Weiming]

Assume LFB with following attributes

foo1, type u32, ID = 1

foo2, type u32, ID = 2

table2: type array, ID = 4
 elements are:
 j1, type u32, ID = 1
 j2, type u32, ID = 2
[Weiming] Let me add one more field as
 j3, type u32, ID=3

Then, very often, we may have operations as:

1) delete(or get ) all entries with j1=100, and j2=200 (note j3 is not cared)
2) modify entry with index=10 to j1=100, and j2=200 (note j3 is not to be
changed)

If we allow field ID in Data, this can be expressed easily. I just see some
difficulty using the encoding you and Joel proposed. For 2) you may say it can
be done by using two separate Path-data, but I just think this way is very
tedious, saying if we have 10 fields more. If we allow field ID in data, it can
be tidily expressed.
[/Weiming]

table1: type array, ID = 3
 elements are:
 t1, type u32, ID = 1
 t2, type u32, ID = 2  // index into table 2

[Weiming] I think a compund structural type is very common, which should be
instanced  in the example.  Let me show one as:

foo3, type structure, ID=5
{
    s1, type u32, ID=1
    s2, type structure, ID=2
    {
        g1, type u32, ID=1
        g2, type u32, ID=2
    }
 }

For this type, we then may also have very common operations as:
        Modify s1 to 100 and g1 to 200.
I also see some tidious problem if we don't allow field ID in the DataTLV.
[/Weiming]

1) To get foo1
Path IDs = 1

Result:
Path = 1, DATA_TLV with value of foo1

2) to set foo2 to 10
Path IDs = 2
DATA_TLV: L = 4+4, V=10

3) To dump table2 (get)
Path = 4

Result:
Path = 4
DATA_TLV, Length = 4 + (#of entries in table2)(8+4)
This is followed by data of the form:
subscript,j1value,j2value (subscript is 4 bytes, j1 + j2 is 8 bytes)

Note the above allows for holes in subscripts, i.e if subscript is
not in use it doesnt take space
[Weiming] Note that some tables may or may not have subscript, above format will
then result in ambiguity in semantics. If we uniformly ask IDs in Data, no such
problem then.



_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol