[SWMP] faster field messages

"Jay C. Weber" <jweber@mediamachines.com> Fri, 24 August 2007 16:18 UTC

Return-path: <swmp-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IObri-0005tf-3R; Fri, 24 Aug 2007 12:18:30 -0400
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IObrg-0005kN-66 for swmp@ietf.org; Fri, 24 Aug 2007 12:18:28 -0400
Received: from worlds.webers.org ([] helo=william.mediamachines.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IObrf-00007D-QI for swmp@ietf.org; Fri, 24 Aug 2007 12:18:28 -0400
Received: from [] (h-66-134-93-202.snvacaid.covad.net []) by william.mediamachines.com (Postfix) with ESMTP id 4BD99464005; Fri, 24 Aug 2007 11:16:16 -0500 (CDT)
Message-ID: <46CF04CF.7080903@mediamachines.com>
Date: Fri, 24 Aug 2007 09:18:23 -0700
From: "Jay C. Weber" <jweber@mediamachines.com>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: john_patterson@us.ibm.com
References: <OFE08B3427.B3EA5603-ON8525732C.0077710F-85257333.0024F03B@lotus.com>
In-Reply-To: <OFE08B3427.B3EA5603-ON8525732C.0077710F-85257333.0024F03B@lotus.com>
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: swmp@ietf.org
Subject: [SWMP] faster field messages
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="===============0043166985=="
Errors-To: swmp-bounces@ietf.org

john_patterson@us.ibm.com wrote:
F)  The use of the fieldId on the SET message as a way to allow faster field references seemed to require modification.  For one thing, it did not seem right that the name/id association was being defined by the requesting network element rather than the network element controlling the state.
It's really about this:  element A needs to specify a <node,field> in a message to element B.  If A sends B a number of such messages, it's worth setting up a shorthand for that pair.  Thus my SWMP design was to add a message parameter to SET, a non-negative integer fieldId, that when non-zero means "if I use this fieldId in the future it means this <node,field> pair".  And I created a SETF message that uses the fieldId.  Thus one SET message would be followed by many SETF messages, the advantage being that SETF messages are much shorter.

It doesn't matter what the architectural roles are of A and B, it's just a bilateral mechanism to create a shorthand, and it makes sense to me that the element that coins the <node,field> pair is the one to coin the shorthand for it.

Jay C. Weber, Ph.D.
CTO, Media Machines Inc.
SWMP mailing list