[Ndn-interest] [EXT] Custom TLV vs library
varunpatil at ucla.edu
Wed Jan 20 11:26:50 PST 2021
> Both NDN-TLV and CBOR can be considered "standardized" in the context of
> NDN applications.
> You can choose either one, but you should write down the schema first. In
> other words, CBOR is not an excuse for not writing the schema.
At least for my use case, there isn't a schema - I just need to encode an
unordered_map<string, int>. Which is why CBOR seemed ideal.
> Caution: not every CBOR implementation supports every CBOR feature. Thus,
> it may end up being more complicated than NDN-TLV.
Ah didn't consider this. I guess NDN-TLV seems like a more consistent
solution to go with then.
> Sidenode: I've used CBOR in the past. See my name on
> https://github.com/PelionIoT/cbor-sync and
> https://github.com/bergos/ArduinoCbor .
> Yours, Junxiao
> On Wed, Jan 20, 2021 at 6:49 AM Varun Patil <varunpatil at ucla.edu> wrote:
>> *External Email*
>> Hi Junxiao,
>> Thanks for the (very insightful) reply.
>> If I understand correctly, both reasons to choose NDN-TLV have to do with
>> not adding a dependency.
>> My argument for CBOR is similar to the reason we use JSON over arbitrary
>> formats - a highly standardised encoding will give better results in the
>> long term.
>> But on the other hand it introduces inconsistency, so I will stick with
>> NDN-TLV unless there is more encouragement from the community that we want
>> to try out a new standard.
>> Any other thoughts?
>> On Wed, Jan 20, 2021, 12:31 AM Junxiao Shi <shijunxiao at email.arizona.edu>
>>> Hi Varun
>>> There is no fundamental difference between NDN-TLV and CBOR.
>>> In either case, you would need to define a clear and unambiguous schema
>>> on how each object is encoded.
>>> NDNts has already implemented PSync and syncps
>>> <https://ndnts-docs.ndn.today/typedoc/modules/sync.html>, and will
>>> implement SVS once your protocol is reasonably stable.
>>> Reasons for choosing CBOR
>>> CBOR have a machine readable schema language (CDDL, RFC8610
>>> NDN-TLV only has ABNF schema definition, and this definition often
>>> depends on comments to express semantics.
>>> Reasons for choosing NDN-TLV
>>> General purpose NDN-TLV encoder and decoder are available in most
>>> CBOR would be an additional dependency, which increases code size,
>>> especially for webapps and microcontrollers.
>>> If you need to encode NDN elements, such as a name or a certificate, it
>>> is natural to embed NDN-TLV inside NDN-TLV.
>>> It has been argued
>>> <https://zjkmxy.github.io/posts/2020/07/tlv-reflection/>that NDN-TLV
>>> codec should use the "reflection" feature, if available in the programming
>>> python-ndn has an implementation of this idea. Additional experiments
>>> <https://github.com/zjkmxy/ndn-encoding-test>are being done for Go.
>>> This would make programming with NDN-TLV easier.
>>> Yours, Junxiao
>>> On Mon, Jan 18, 2021 at 11:11 AM Varun Patil <varunpatil at ucla.edu>
>>>> *External Email*
>>>> I've been developing a StateVectorSync library (named-data/ndn-svs),
>>>> and there seem to be two approaches to encoding the state vector:
>>>> 1. An NDN custom TLV.
>>>> 2. A standardised serializer. Currently the library uses
>>>> boost-serialization, but I'm in favor of CBOR (RFC 8949, Standards Track,
>>>> Dec. 2020). This would make it easier to write compatible SVS libraries in
>>>> other languages, since CBOR decoders are already available in virtually
>>>> every language (also it may be more space efficient than custom TLV blocks).
>>>> Any thoughts/suggestions on which is the better approach?
>>>> Varun Patil
>>>> Graduate Student
>>>> Computer Science, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest