[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf 11. Setcli accessor function - Item to be resolved on email list

On observing the exchange between Joel and Jeff and in the absence of
other comments, I have not seen a lot of support for the idea and while
I think Jeffs points are helpful, they fix things that really are not
issues today (that I know of) but might be if we were to introduce this

> >I must be missing something.   I do not understand the value of our 
> >standardizing "the name of the function and the minimum error 
> >behavior".  Given that the parameters will be different for different 
> >systems, having the name the same actually seems almost 
> >counter-productive.  It certainly does not seem like something we should be 
> >puttting time and energy into at this point in the process.
> one of us is missing something but it may be me
> here is a bit more about what i was thinking ...  if one has an
> implementation-specific feature, like we are discussing, one error
> that i think is likely to happen in practice is that somebody will
> download and attempt to run a script for a flintstone router onto a
> yogiberra router
> if the names of the accessors and the minimum error behaviors are not
> standardized, then you get a generic error that is indistinguishable from
> a language syntax error, e.g., a typo and any recovery is impossible
> if, however, you have a standard for the accessor, you can define minimal
> error behaviors like
> 	no cli subsystem
> 	cli syntax error
> 	and the like (perhaps more, perhaps not)
> then, a prudent coder can do some defensive driving against these common
> errors as we have been taught to do (but do all too seldomly)
> 	[i am aware that you could achieve the same result via use of an
> 	additional generic accessor function similar to the c-shell operator
> 	" -e " for file inquiries, but this seems to be an unnecessary and
> 	unwarranted complexity unless justified elsewhere and that seems
> 	pretty unlikely]
> i think that the diagnostic benefits of an error mechanism that is more
> specific and localized to the the problem rather than less specific are
> uncontroversial, but, then, i thought that the above was uncontroversial
> if this turns out to be real contentious, i am reluctantly willing to
> duck and cover in the interest of timely progress on other issues
> perhaps if i had not been prevented from being able to join you in san diego, 
> i would be better equipped and able to anticipate how controversial this
> might be
> regards,
> jdc


Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874