Subject: Re: Protocol Operations

From: "Putzolu, David" <[email-masked]>
Date: Tue, 8 Feb 2005 08:49:15 -0800

(speaking just as another technical guy here) 

This seems overly complex to me.  Is there a common case that motivates
the need for this?

-David

> -----Original Message-----
> From: Forwarding and Control Element Separation 
> [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
> Sent: Tuesday, February 08, 2005 6:16 AM
> To: [email-masked]
> Subject: Re: [FORCES] Protocol Operations
> 
> I am not sure i got the SETRESULT; going by what Weiming asked for
> earlier, we have the following facilities:
> 
> To set data to a 3-deep path offset:
> path-data
> 	path1
> 	optional selector
> 	path-data
> 		path2
> 		optional selector
> 		path-data
> 			path3
> 			optional selector
> 			dataraw
> 
> 
> If a response is asked back, thats exactly how the response would look
> like as well.
> 
> The other way which is to set data on multiple nested paths:
> 
> path-data
> 	path1
> 	optional selector
> 	dataraw
> path-data
> 	path2
> 	optional selector
> 	dataraw
> path-data
> 	path3
> 	optional selector
> 	dataraw
> 
> Granted the end result will be grossly ineefficient since it 
> will have a
> lot of redundant information in the three path-datas above if path1 is
> relative to path2 and path3 is realtive to path2.
> For this we can use what i have seen in a few classifiers as an
> optimization; these sorts of classifiers hacve a  "continue" construct
> which translates to "continue looking up where you last left off".
> We can have something similar as a flag - so on path2 and 
> path3 it would
> say "the previous path+selector counts as part of this path". 
> So path1 +
> its selectors will be part of path2+ its selectors, which is also part
> of path3 and its selectors. Clearly the flag is not useful on 
> the first
> path-data it involves inheritance and can be ignored there.
> 
> Heres my worry: I think what Weiming wants in this case is a 
> corner case
> which while we must satisfy the end result should not break the simple
> design rule of "optimize for the majority"
> 
> cheers,
> jamal
> 
> On Tue, 2005-02-08 at 06:59, Joel M. Halpern wrote:
> > You raise an interesting question of where the element by 
> element SET 
> > results go.
> > 
> > One of the drawbacks of allowing multiple path-data 
> elements inside a 
> > operation TLV is that it no longer suffices to return the 
> response code at 
> > the operation TLV level.
> > Therefore, I would presume, we will have to return the 
> response codes in 
> > the individual path-data TLVs.
> > I would not want to return the results as a separate 
> parallel TLV, as that 
> > would imply some kind of matching that would get quite 
> confusing.  I 
> > suppose that means that the actual syntax becomes:
> > 
> > DATAINFO := [SELECTOR] [<PATH-DATA>+ | <DATARAW>+ | <SETRESULT>+]
> > 
> > Where SET Result is used only in the response to a SET, and 
> occurs where 
> > the DATARAW elements were in the set request, indicating 
> for each dataraw 
> > whether it was successfully set.
> > 
> > Yours,
> > Joel
> > 
> > At 11:22 PM 2/7/2005, Wang,Weiming wrote:
> > >It quite gets to me that the list server often ate my 
> posts. I do have 
> > >sent some mails but that cann't be seen on the list till now.
> > >
> > >Hopefully  this post can work.
> > >
> > >----- Original Message -----
> > >From: "Joel M. Halpern" <[email-masked]>
> > >Subject: Re: Protocol Operations
> > >
> > >
> > > > I actually think we could get away with:
> > > >
> > > > DATAINFO := [SELECTOR] [<DATARAW> | <PATH-DATA>+]
> > > >
> > > > and just leave out the "DATA" line.  I believe this 
> allows the nesting, is
> > > > decidable by the parser, and does what we need.
> > > >
> > > > we can in fact collapse further in the BNF to:
> > > >
> > > > PATH-DATA TLV := <PATH> [SELECTOR] [<DATA>+ | <PATH-DATA>+]
> > >
> > >Yes, this makes it more clear, but I still see the value 
> to modify it to:
> > >
> > >PATH-DATA TLV := <PATH> [SELECTOR] [<PATH-DATA>+] [<DATA>+]
> > >
> > >I suppose  a SET request that has format as "path 
> path-data1 path-data2 
> > >path-data3", whos response will have format as "path 
> path-data1 path-data2 
> > >path-data3 data", the last data TLV is for the SET result 
> responses.
> > >
> > >Cheers,
> > >Weiming
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 8 Feb 2005 12:13:32 -0500

> This seems overly complex to me.  Is there a common case that motivates

Weiming wants to be able to set data values as he walks hierachies of
attributes. As an example, tables which may have cells pointing to other
tables which may have cells pointing to other tables etc - and you want
to set cell in first table, then cell in following table etc. 

I think its a reasonable desire, but i contend it is not common.
It is fair to punish the uncommon cases and have them do more work
(parsing). Hence i would claim its ok to complicate things for that
scenario. Unless i missed the target of your comment as to what is
complex.

[Take a look at some of the examples in the text where i have been
capturing things to see some of what i think is common].

cheers,
jamal