[SWMP] Re: field-creation semantics

Jay:

I think you are right.  This one is mostly a matter of taste.  I tend to 
look for the CRUD (Create, Read, Update, and Delete) operators as soon as 
I see any state management.  So, I find it easier to understand the 
protocol or API when these operators are expicitly available.

To reiterate something I said before, I don't think one should equate 
message count with simplicity.  The two legitimate complexity concerns 
seem to me to be complexity for the implementation and complexity for the 
user.  Implementations can be simpler when different operations are 
clearly differentiated.  The user's comprehension is facilitated when 
overloading is avoided.

Having said all that, while I prefer differentiating SET and ADD, it is 
not a biggy for me.

jfp

"Jay C. Weber" <jweber@mediamachines.com> 
08/24/2007 12:01 PM

To
john_patterson@us.ibm.com
cc
swmp@ietf.org
Subject
field-creation semantics

john_patterson@us.ibm.com wrote: 
C)  SET is overloaded as both a way to change and create (and probably 
remove) a Field.  I think it is clearer to separate these operations. This 
leads to an ADDFIELD, REMOVEFIELD, and a SETFIELD.  Then for clarity ADD 
and REMOVE need to become ADDNODE and REMOVENODE. 
It's true that setting a previously-nonexistent field had the side-effect 
of "creating" the field.  Or, one could think of it as all fields exist, 
but have undefined values until set.  This is usually the semantics of 
associative arrays, and has a useful simplicity, e.g., in web DOM and some 
XML apis.  I guess it's a matter of taste, but it is a way to keep the 
protocol simpler.

jay
-- 
Jay C. Weber, Ph.D. 
CTO, Media Machines Inc. 
650-279-2311 