[2] RE: [Forces-protocol] RE: GET/SET in one msg ?

[Jamal Hadi Salim <[e-mail]>]

On Sat, 2004-10-16 at 23:45, Zsolt Haraszti wrote:

> On Sat, 2004-10-16 at 11:29, Jamal Hadi Salim wrote:

> Assuming the SET/ADD/DEL CONFIG-REQUEST operators (I use ADD
> here instead of INS, because I slightly prefer ADD over INS;
> but otherwise it has the same meaning as INS in all previous
> discussions), all we need for the above purpose is a single flag:
> F_PEDANTIC (or F_PICKY).  (We can choose the inverse meaning, but
> I could not come up with a good word to describe that...)

If you assume BSDism (probably std database table manipulation) then a
single flag is insufficient.
You need the equivalent of EXCL and REPLACE.
i.e an ADD with EXCL|REPLACE to a table implies create and update
with passed values. This allows you to at times just create and
have default values populated.
You seem to be saying a ADD = CREATEing an element and a SET is an 
update to an existing entry?

> Before further discussing the meaning of this flag, a couple of
> notes:
> 
> 1. For SET operations this flag plays a role only if path
>    refers to an entry in an ARRAY data element, i.e., when
>    path[:-1] refers to an ARRAY (in which case path[-1] is the
>    index to be used inside the ARRAY).  In all other cases the flag
>    must be ignored.
> 

We may be on the same page, you are refering to non-terminal in this
case.

>    (Notation hint: path refers to the list of IDs, path[-1] refers
>    to the last element of the list, and path[:-1] means the
>    first part of the list without the last element.)
>
>    So the meaning of the flag in this scope is as follows:
> 
> 	if element[path] exists:
> 		element[path] = data
> 		report success/failure of assignment
> 	else:
> 		if OP_FLAGS & F_PEDANTIC:
> 			report error
> 		else:
> 			# attempt to add new element to array:
> 			add(element[path[:-1]], # ARRAY
> 			    index=path[-1],	# INDEX
> 			    value=data)		# initial value
> 		report success/failure of assignment
> 
>    In words, if F_PEDANTIC is cleared, create entry if it
>    does not yet exist.  If F_PEDANTIC is set, report error
>    if entry does not yet exist.
> 

Ok, now i am sure we mean the same thing, except you have separated 
update from create.
I think it is valuable to keep them together.

> 2. For ADD/DEL operations:
>    We will have actually two forms of ADD/DEL operations:
>    a  One where path specifies the entry in an ARRAY which is
>       to be added/deleted, i.e., path[-1] is the entry index
>       within the ARRAY, and path[:-1] is the reference to the
>       ARRAY itself.
>    b  Another where path refers to the ARRAY itself and the
>       index/indices of the entries to be added/removed are given
>       as part of the [block] description.  (For the ADD the
>       indices may not be provided at all, in which case the FE
>       can pick the indices; a.k.a. INS vs. INS_IDX.)
>       Obviously this b) form is meant for block operations,
>       though b. can do what a. can.  I still would like to
>       allow both forms because in single-entry operations the
>       a. form is more staright-forward.
>
>    BTW, we will have to signal in the OP TLV header
>    which form we mean, because in the special case when
>    both path[:-1] and path refer to an ARRAY (i.e., path[:-1]
>    is an ARRAY of ARRAYs), the above two forms collide.  This
>    can be done via an F_BLOCK flag indicating b. when set,
>    or separate SET/SET-BLOCK, ADD/ADD-BLOCK, and DEL/DEL-BLOCK
>    operations (T's).  Flags are OK.
> 
>    Now, the meaning of the F_PEDANTIC flag (assuming the above
>    scope conditions are satisfied) is as follows:
> 
>    For ADD as in a.:
> 
> 	if element[path] does not exists:
> 		add(element[path[:-1]], # ARRAY
> 		    index=path[-1],	# index
> 		    valude=data)	# initial value
> 		report success/failure of assignment
> 	else:
> 		if OP_FLAGS & F_PEDANTIC:
> 			report error
> 		else:
> 			element[path] = data # over-write element value
> 			report success/failure of assignment
> 
>    For ADD as in b.:
> 
> 	for index in BLOCK: # Take each index specified in BLOCK
> 		# Do the same as above pseudo code, but replace
> 		# path with path+index, path[:-1] with path,
> 		# and path[-1] with index
> 		if element[path + index,] exists:
> 			add(element[path], index, data)
> 			report success/failure
> 		else:
> 			if OP_FLAGS & F_PEDANTIC:
> 				report error
> 			else:
> 				element[path + index,] = data
> 				report success/failure
> 
>    For DEL as in a.:
> 
> 	if element[path] exists:
> 		del(element[path[:-1]], index=path[-1])
> 		report error
> 	else:
> 		if OP_FLAGS & F_PEDANTIC:
> 			report error
> 		else:
> 			report success
> 
>    For DEL as in b.:
> 
> 	for index in BLOCK:
> 		if element[path + index,] exists:
> 			del(element[path], index)
> 		else:
> 			if OP_FLAGS & F_PEDANTIC:
> 				report error
> 			else:
> 				report success
> 
> By now you can infer the overall meaning of the F_PEDANTIC flag:
> If cleared, the FE should try to correct/ignore the element existence
> issue if there is one; if set, the FE must regard any entry existence
> issues as error and handle it accordingly.
> 

Ok, so the conclusion i reach is you have separated CREATE from UPDATE,
everything else seems to be the same (you didnt refer to terminals vs
non-terminals). In what i described earlier both are under the same
umbrella of ADD with differentiation being the flags. Is there any good
reason you are deviating from the norm (or what i consider to be the
norm). To compare against netlink and BSD route socket approach in
operations to ADD:

F_REPLACE: Replace existing matching config object with
         this request.
F_EXCL: Do not replace the config object if it already
         exists.
F_CREATE: Create config object if it does not already
         exist.

BSD ADD operation equates to F_CREATE or-ed with F_EXCL

BSD CHANGE operation equates F_REPLACE

BSD Check operation equates F_EXCL

BSD APPEND equivalent is actually mapped to F_CREATE

The existence of a passed index is actually in addition to the above.

> > 
> > A CREATE operation with F_EXCL|F_REPLACE is equivalent to SET!
> > 
> > ** Other flags used for block operations mentioned in the BLOCK
> section.
> > 
> > BLOCK and KEY path selection
> > -----------------------------
> > 
> > The <all> variant described in [1] is not needed. To get access
> > to all of table contents, the IDs merely need to point to the table.
> 
> True.  But with whatever notation you will come up to define the
> BLOCK, it will always allow for encoding the ALL case as an extreme
> case.  And I don't think we should make that case illegal.
> 

What i meant is if i wanted to get table 7 then my ID will be 7.
The BLCOK will be a further filter.

> > Therefore to access a range, the IDs field will contain the ID
> > leading to a table and an optional TLV will include the range
> > information.
> > 
> > - Additional flags needed:
> > 1)F_BLOCK_ON, to indicate block selector embeded
> > 2)F_KEY_ON, to indicate a key selector embeded
> 
> ACK
> 
> > #1 and #2 are mutually exclusive.
> 
> I agree provided that the KEY can include multiple keys of the
> same key type.
> 

Makes sense.

> > 3) F_REV_TRAVERSE, to indicate reverse progress in the access.
> 
> I guess this would be meaningful only in QUERY (GET) operations,
> but I would NOT bother with this option.
> 

It was mentioned in the doc you guys posted; will restrict it to being a
flag.

> > 4) F_KEY_MODE (2 bits or more) to select the KEY mode in case #2 is
> > on.
> > 5) F_BLOCK_MODE (1 bit); indicates count or range for second
> > parameter of BLOCK Notation.
> > 
> 
> It may be cleaner to encode these modes inside the respective TLV,
> either as separate T values or as a special flag in the value part.

The start/end values are a TLV as shown below. Did you mean something
else?

> > In the case of block operations: 
> > 
> > Two modes exist. [a,b] or [a,N]
> > We introduce a block TLV
> > 
> > T = BLOCK_TLV
> >     start // "a"
> >     end // "b" or "N"
> > 
> > The flag F_BLOCK_ON will indicate the presence of this TLV.
> > F_BLOCK_MODE will indicate that "end" is an "a" or "N"
> > F_REV_TRAVERSE will indicate whether reverse or forward progress
> > 
> > In the case of the associative paths: 
> > the flag F_KEY_ON will indicate that we are using associative approach
> > F_KEY_MODE will define the mode .
> > 
> > We introduce a KEY_INFO TLV.
> > 
> > T = BLOCK_TLV
> 
> You meant KEY_INFO_TLV, I assume.
> 

Of course ;-> That was intentionaly entered bug to see if people read
the doc ;-> Now i know you paid good attention ;->


> >     KEY
> >     KEY_DATA
> > 
> > The length of the TLV will help deducing the size of the KEY_DATA.
> 
> I presume KEY specifies the key-type (in case more than one type
> of keys are allowed on the target).  Remember: each key type is a
> collection of the struct fields that together can form a key.
> 
> KEY_DATA is one **or more** data blocks satisfying the KEY definition.
> Each data block contains the necessary field values according to
> the KEY definition.
> 

The content aspect of things i dont have good clarity on. so provide me
with better definition on how things should be laid out and i will
update the doc.


> > 
> > DATA:
> > -----
> > Not discussing the optional data right now; a lot of details
> > above need ironing out first.
> > DATA is complex twist when it comes with variable sized data.
> 
> Steve and I will propose an encoding soon, to start that discussion.

Factor in the litmus test i provided in earlier email.

cheers,
jamal


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