Re: [Forces-protocol] Data Encoding

"Joel M. Halpern" <> Wed, 17 November 2004 15:25 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA08117 for <>; Wed, 17 Nov 2004 10:25:57 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.33) id 1CURjH-0003Rx-Fv for; Wed, 17 Nov 2004 10:28:30 -0500
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CURYH-0000FW-Ab; Wed, 17 Nov 2004 10:16:57 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CURTQ-0006eP-Gg for; Wed, 17 Nov 2004 10:11:56 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA06458 for <>; Wed, 17 Nov 2004 10:11:54 -0500 (EST)
Received: from ([] helo=EXECDSL.COM) by with esmtp (Exim 4.33) id 1CURVg-000381-Ep for; Wed, 17 Nov 2004 10:14:27 -0500
Received: from [] (HELO by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7966559; Wed, 17 Nov 2004 10:11:37 -0500
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 17 Nov 2004 10:11:15 -0500
To: Weiming Wang <>,
From: "Joel M. Halpern" <>
Subject: Re: [Forces-protocol] Data Encoding
In-Reply-To: <002401c4ccb0$be49bb30$020aa8c0@wwm1>
References: <> <1099911200.2169.29.camel@jzny.localdomain> <134f01c4c585$216584c0$> <> <142a01c4c6d6$13569980$> <1100100893.2210.24.camel@jzny.localdomain> <14fc01c4c79f$75231f20$> <> <155001c4c8c0$5eb73ec0$> <1100269665.1106.30.camel@jzny.localdomain> <156501c4c8c5$1fb19220$> <1100271071.1109.38.camel@jzny.localdomain> <1100307886.1110.20.camel@jzny.localdomain> <> <009a01c4c934$99cf7990$020aa8c0@wwm1> <> <1100381538.2212.914.camel@jzny.localdomain> <> <1100458281.2327.23.camel@jzny.l! ocaldomain> <009e01c4cb24$ba144bd0$020aa8c0@wwm1> <1100610279.1152.33.camel@jzny.localdomain> <> <002401c4ccb0$be49bb30$020aa8c0@wwm1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: "Khosravi, Hormuzd M" <>, "(Ram Gopal )" <>, Avri Doria <>,, Patrick Droz <>,, Steve Blake <>,, Dong Ligang <>, Robert Haas <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: forces-protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9

Yes, the instance selection process will essentially involve inserting the 
indices into the path.  But the semantics for what is being targetted can 
be determined without such interleaving.

Separating the indices from the path is a compromise.  From an analytic 
point of view, I would like to include the indices in the path.  With the 
push for content addressing, and some folks asking for block selection, The 
path would get too messy if the indices where in it.  SO I just end up 
concluding that the best compromise is to separate the indices from the 
path and from the data.

Just my personal conclusion,

At 09:21 AM 11/17/2004, Weiming Wang wrote:
> > The more I think about it, the more I like three sets of information,
> > first the base path (length, sequence of identifiers)
> > then one or more TLVs for the subscripts, where the TLV wil contain an
> > index identifier and the data to be used as a subscript.  This may be the
> > base subscript, or some other field.  (The identifier is a field identifier
> > rather than a type identifier since there might be two key fields for the
> > same table with the same type, but differing values.)
> > Then for modify operations (and GET responses?) a TLV for the actual data.
> > If we want to allow block references, then the structure of the subscript
> > TLV can be expanded to indicate ranges somehow.
> > This keeps the notions of "what structural thing", "which instance", and
> > "what value" cleanly separated.
>[Weiming] I understand your state as first coming the field IDs, then the
>indexes, and last the values. A little worry is that in some cases, the field
>IDs and the indexes have to be interfered to reference an entry, that is, the
>path may be something liek fieldID.index.fieldID, When the index appear in the
>path is important for correct addressing, that is, fieldID.index.fieldID is
>different from fieldID.fieldID.index, therefore, to separately express fieldID
>and indexes may make things more complex.

Forces-protocol mailing list