Re: [core] Designs to resolve streaming issues in SenML

Michael Koster <michaeljohnkoster@gmail.com> Sat, 16 January 2016 17:44 UTC

Return-Path: <michaeljohnkoster@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE751A905C for <core@ietfa.amsl.com>; Sat, 16 Jan 2016 09:44:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pxw_lMcMSim for <core@ietfa.amsl.com>; Sat, 16 Jan 2016 09:43:59 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CEA71A905D for <core@ietf.org>; Sat, 16 Jan 2016 09:43:59 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id q63so138360713pfb.1 for <core@ietf.org>; Sat, 16 Jan 2016 09:43:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=MR+nx1AodjxYVd/PXKjz3ipCk6DZc4E/Luj9hdd2qvo=; b=NtcTHSzv5WwnpbXNy5F1PaqlSOZtqLM418nAZB7itgN2syBQbrnBAWiPxquvMBFTtR wCvPYvwFa9P2ZQbsfYwR6GSsxA5C7jgmpIFH39UtWPvyFrPGxBCS8ec6JTPLao/XGL1c FMMoKUsSFHdNNxkNzmymVcumGAPPB9+Sq4trQ0I7AkcbMjwn3brXQFO3lQFvNu+51AV3 psqa9/DWIek3YXwDyX9pWEBEiSiBp3vtL26EN6VqDwuWC4karngLuIgxS0Re03ItArlz fbjwGKTRPY42IM1OU/BG+975osvrzIiDgKUWSZCkHiZnW6HPENyjQTvydSkgL8mSJPa5 jVMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=MR+nx1AodjxYVd/PXKjz3ipCk6DZc4E/Luj9hdd2qvo=; b=fNqjMXAMYJn8u3NHbyVEH7S4uUoWWO0pfv23nyV2Hx9rvRx6R5WutA15rXpNQKy6Uq F3ZbFX4GGTRrb3RYHOUsVihQIPDBckZryybKyu8CUMGXwtGPH7/vf2mvS05ZCyPADG3g /XbowLx9j8fp8xBuAZExZsm/0UxEM7scku5fOVrvandO8vVx7kBrzayLqDY3UYXhTbD4 xuy0xeyeMyKnFKL6LyoSM7ZjXHjry5tR92ycxLj26r/hN7gqmiby6dgvruY67ns8rgx3 gkjKdH94/Ob+R89tlJbTUo2xvPWoYUJP6GGF2xycQDRAaqMgbnp694OtsyAaiCEbknxH /WRQ==
X-Gm-Message-State: ALoCoQmh+198IY5s+hCx6yH4zaTMfcfpSVqaWnem+PnA9KEVmFYAa82ckfAX9nwUzW/rYVtnsCFKxbsAVdUoWLysTD8RQv3Q1A==
X-Received: by 10.98.68.193 with SMTP id m62mr23966658pfi.153.1452966238537; Sat, 16 Jan 2016 09:43:58 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id l9sm23144589pfb.29.2016.01.16.09.43.56 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 09:43:57 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6C3C2692-6D73-4D56-B1A9-67908E9D02A4"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster <michaeljohnkoster@gmail.com>
In-Reply-To: <569A6B27.50404@tzi.org>
Date: Sat, 16 Jan 2016 09:43:55 -0800
Message-Id: <7DA00BBA-4869-4351-97E3-6B45311B28A2@gmail.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <20160116132751.GB18563@hephaistos.amsuess.com> <CC28D44A-DBC0-446D-90A8-3E329FC3F0AF@gmail.com> <569A6B27.50404@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/wNq10j01TpMBOMs_I3pWcEQmDa8>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, core <core@ietf.org>, Christian Amsüss <c.amsuess@energyharvesting.at>
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jan 2016 17:44:02 -0000

Hi Carsten,

Yes, of course! This approach reminds me of JSON streaming, where actual delimiters are inserted into a text stream, but this is much better because it uses the JSON array itself to encapsulate elements that can be individually parsed.

That makes the outer element an array and the inner elements either array type or map map type, and the map can be extended to embed element types representing the links, forms, and data within the base element dictionary.

It would be useful if the order of top level element types could be arbitrary e.g.: [ {},[],[],[],{},[],{},{} ... ]

So for example, to use this format I will extend the base element map as you indicated:

[ 
  { "bn": "urn:dev:mac:0024befffe804ff1/",
    "l": [
       {"href"...}...
    ]

  },
  [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
    { "n": "current", "t": 0, "u": "A", "v": 1.2 } 
  ]
]

If the order of top element types is optional, then the presence also could be, so I can adapt the new format by extending the base element to include links, forms, and items (getting rid of the “e” tag):

[ 
  { 
    "bn": “/light/brightness",
    "l": [
      { “href”: “change”,
        “rt”: [“change”,”form”],
        “ct”: “application/forms+senml+json”
      },
      { “href”: “tbr”,
        “rt”: [“property”, “item”, “param"],
        “ct”: “application/senml+json”
      },      
      { “href”: “tt”,
        “rt”: [“property”, “item”, “param"],
        “ct”: “application/senml+json”
      },
      { “href”: “actuations”,
        “rt”: “actuation”,
        “ct”: “application/collection+senml+json”
      }     
    ],
    “f”: [
      { “id”: “change”,
        "href”: “actuations”,
        “ct”: “application/collection+json”,
        “method”: “post”,
        “type”: “change”
        “template”: {
          “tbr”: “$targetbrightness”
          “tt”: “$transitiontime”
        }
      }
    ],
    “i”: [
      { “n”: “tbr”,
        “v”: “44.3”,
      },
      { “n”: “tt”,
        “v”: “1.0”,
      }
    ]	
  }
]

Having a top level array will allow me to accommodate collective operations on multiple object (bases) and allow the underlying implementation to chunk things at lease to the granularity of base objects mapped to top level elements.

So I’m OK with this if it allows me to use base elements as above.

Best regards,

Michael



> On Jan 16, 2016, at 8:09 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> Michael Koster wrote:
>> What is missing still from everything after -01 is the element tag that
>> I am re-using to indicate links and forms in the document:
> 
> What would be wrong with including this in the metadata part of -02:
> 
>   [{"bn": "urn:dev:mac:0024befffe804ff1/",
>     "l": [
>      {"href"...}...
>     ]},
>    [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
>      { "n": "current", "t": 0, "u": "A", "v": 1.2 } ]
>   ]
> 
> Grüße, Carsten