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

Carsten Bormann <cabo@tzi.org> Fri, 15 January 2016 09:17 UTC

Return-Path: <cabo@tzi.org>
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 6C4881A8AFE for <core@ietfa.amsl.com>; Fri, 15 Jan 2016 01:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 A5ObBncThWeZ for <core@ietfa.amsl.com>; Fri, 15 Jan 2016 01:17:34 -0800 (PST)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E9A1A8AF6 for <core@ietf.org>; Fri, 15 Jan 2016 01:17:34 -0800 (PST)
Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 1A5AA41C0B1; Fri, 15 Jan 2016 10:17:33 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 4VTqpAGDmm3R; Fri, 15 Jan 2016 10:17:31 +0100 (CET)
X-Originating-IP: 93.199.254.229
Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 65D0C41C0A2; Fri, 15 Jan 2016 10:17:31 +0100 (CET)
Message-ID: <5698B929.90008@tzi.org>
Date: Fri, 15 Jan 2016 10:17:29 +0100
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Michael Koster <michaeljohnkoster@gmail.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <85DB69FC-A20E-4314-AAB0-5E8AA8B5E5E6@gmail.com>
In-Reply-To: <85DB69FC-A20E-4314-AAB0-5E8AA8B5E5E6@gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/i18rOjW5e0uW5BOaN96hvbuw8nE>
Cc: core <core@ietf.org>
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: Fri, 15 Jan 2016 09:17:35 -0000

Indeed, SenML -01 is optimized for implementations that ingest the
entire SenML document and then work on the result -- exactly what
happens in your Python implementation.

What -02 was trying to do was to also enable implementations operating
sequentially (what somewhat misleadingly has been called "streaming" --
well yes, enabling sequential processing is a prerequisite to enabling
streaming, but streaming is not the only reason for wanting to enable
sequential processing).

But of course this should not detract from the usefulness of the format
for ingest-bang implementations.
I think the structure in -02 is quite close to meeting both objectives.
I agree that the recent changes have led us away from that.

(I must admit I don't care as much about a complete analogy between XML
and CBOR formats; but as we now have found someone who cares about the
XML variant, we might be able to fix that.)

Grüße, Carsten