[SWMP] Re: field-creation semantics
john_patterson@us.ibm.com Fri, 24 August 2007 16:22 UTC
Return-path: <swmp-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IObvw-00080z-Ha; Fri, 24 Aug 2007 12:22:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IObvv-00080r-K3 for swmp@ietf.org; Fri, 24 Aug 2007 12:22:51 -0400
Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IObvu-0005do-9M for swmp@ietf.org; Fri, 24 Aug 2007 12:22:51 -0400
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7OGMlei030268 for <swmp@ietf.org>; Fri, 24 Aug 2007 12:22:47 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7OGMlJP516600 for <swmp@ietf.org>; Fri, 24 Aug 2007 12:22:47 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7OGMlJY018485 for <swmp@ietf.org>; Fri, 24 Aug 2007 12:22:47 -0400
Received: from internet1.lotus.com (internet1.lotus.com [9.33.9.11]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7OGMkPf018463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Aug 2007 12:22:47 -0400
Received: from wtfmail02.edc.lotus.com (wtfmail02.lotus.com [9.33.9.69]) by internet1.lotus.com (8.14.1/8.14.1) with ESMTP id l7OGMkkX022596; Fri, 24 Aug 2007 12:22:46 -0400 (EDT)
In-Reply-To: <46CF00E4.6030207@mediamachines.com>
To: "Jay C. Weber" <jweber@mediamachines.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
Message-ID: <OF5C43A50C.F5988FEA-ON85257341.005940EB-85257341.0059F3E2@lotus.com>
From: john_patterson@us.ibm.com
Date: Fri, 24 Aug 2007 12:23:24 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02/WTF/M/Lotus(Build V703_08192007|August 19, 2007) at 08/24/2007 12:23:29 PM, Serialize complete at 08/24/2007 12:23:29 PM
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Cc: swmp@ietf.org
Subject: [SWMP] Re: field-creation semantics
X-BeenThere: swmp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of a Simple Wide-area Multiuser-3D Protocol <swmp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/swmp>, <mailto:swmp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/swmp>
List-Post: <mailto:swmp@ietf.org>
List-Help: <mailto:swmp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/swmp>, <mailto:swmp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1424574809=="
Errors-To: swmp-bounces@ietf.org
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
_______________________________________________ SWMP mailing list SWMP@ietf.org https://www1.ietf.org/mailman/listinfo/swmp
- Re: [SWMP] Re: faster field messages john_patterson
- [SWMP] My understanding so far john_patterson
- Re: [SWMP] My understanding so far Roland Weber
- Re: [SWMP] My understanding so far Jay C. Weber
- Re: [SWMP] My understanding so far john_patterson
- RE: [SWMP] My understanding so far Tony Parisi
- [SWMP] semantic layers Jay C. Weber
- [SWMP] field-creation semantics Jay C. Weber
- [SWMP] introducing RPC to an asynchronous protocol Jay C. Weber
- [SWMP] Re: semantic layers john_patterson
- [SWMP] faster field messages Jay C. Weber
- [SWMP] Re: field-creation semantics john_patterson
- [SWMP] Re: introducing RPC to an asynchronous pro… john_patterson
- RE: [SWMP] introducing RPC to an asynchronous pro… Tony Parisi
- RE: [SWMP] semantic layers Tony Parisi
- [SWMP] Re: faster field messages john_patterson
- [SWMP] Re: faster field messages Jay C. Weber
- [SWMP] Re: faster field messages john_patterson
- [SWMP] Re: faster field messages Jay C. Weber
- [SWMP] Re: faster field messages john_patterson
- RE: [SWMP] introducing RPC to an asynchronous pro… john_patterson
- RE: [SWMP] introducing RPC to an asynchronous pro… Tony Parisi
- Re: [SWMP] Re: faster field messages Roland Weber
- Re: [SWMP] My understanding so far Roland Weber
- Re: [SWMP] Re: faster field messages Roland Weber
- Re: [SWMP] My understanding so far john_patterson
- Re: [SWMP] My understanding so far Roland Weber
- Re: [SWMP] My understanding so far Jay C. Weber
- Re: [SWMP] My understanding so far Roland Weber