The Concise Binary Object Representation (CBOR) is a data format
whose design goals include the possibility of extremely small code
size, fairly small message size, and extensibility without the need
for version negotiation.  These design goals make it different from
earlier binary serializations such as ASN.1 and MessagePack.

Here is more info about format: http://cbor.io/

You can easily encode and decode things like built-in types, arrays, hash-maps, structs, tuples, classes, strings and raw arrays (ubyte[]).

Here is some simple code:

    import cbor;

    struct Inner
    {
        int[] array;
        string someText;
    }

    struct Test
    {
        ubyte b;
        short s;
        uint i;
        long l;
        float f;
        double d;
        ubyte[] arr;
        string str;
        Inner inner;

        void fun(){} // not encoded
        void* pointer; // not encoded
        int* numPointer; // not encoded
    }

    ubyte[1024] buffer;
    size_t encodedSize;

    Test test = Test(42, -120, 111111, -123456789, 0.1234, -0.987654,
        cast(ubyte[])[1,2,3,4,5,6,7,8], "It is a test string",
        Inner([1,2,3,4,5], "Test of inner struct"));

    encodedSize = encodeCborArray(buffer[], test);

    // ubyte[] and string types are slices of input ubyte[].
    Test result = decodeCborSingle!Test(buffer[0..encodedSize]);

    // decodeCborSingleDup can be used to auto-dup those types.

    assert(test == result);

Here is github link: https://github.com/MrSmith33/cbor-d
Destroy!

On Friday, 19 December 2014 at 18:26:26 UTC, MrSmith wrote:
> Here is github link: https://github.com/MrSmith33/cbor-d
> Destroy!

It would be nice to have a side-by-side comparison with http://msgpack.org/ which is in current use by a couple existing D projects, include D Completion Daemon (DCD) and a few of mine.

On Friday, 19 December 2014 at 18:26:26 UTC, MrSmith wrote:
> The Concise Binary Object Representation (CBOR) is a data format
> whose design goals include the possibility of extremely small code
> size, fairly small message size, and extensibility without the need
> for version negotiation.  These design goals make it different from
> earlier binary serializations such as ASN.1 and MessagePack.
>
> Here is more info about format: http://cbor.io/
>
> You can easily encode and decode things like built-in types, arrays, hash-maps, structs, tuples, classes, strings and raw arrays (ubyte[]).
>
> Here is some simple code:
>
>     import cbor;
>
>     struct Inner
>     {
>         int[] array;
>         string someText;
>     }
>
>     struct Test
>     {
>         ubyte b;
>         short s;
>         uint i;
>         long l;
>         float f;
>         double d;
>         ubyte[] arr;
>         string str;
>         Inner inner;
>
>         void fun(){} // not encoded
>         void* pointer; // not encoded
>         int* numPointer; // not encoded
>     }
>
>     ubyte[1024] buffer;
>     size_t encodedSize;
>
>     Test test = Test(42, -120, 111111, -123456789, 0.1234, -0.987654,
>         cast(ubyte[])[1,2,3,4,5,6,7,8], "It is a test string",
>         Inner([1,2,3,4,5], "Test of inner struct"));
>
>     encodedSize = encodeCborArray(buffer[], test);
>
>     // ubyte[] and string types are slices of input ubyte[].
>     Test result = decodeCborSingle!Test(buffer[0..encodedSize]);
>
>     // decodeCborSingleDup can be used to auto-dup those types.
>
>     assert(test == result);
>
> Here is github link: https://github.com/MrSmith33/cbor-d
> Destroy!

Do you know OGDL ?

http://ogdl.org/

It's currently the more 'appealing' thing to me for serialization.

On Friday, 19 December 2014 at 22:33:57 UTC, BBaz wrote:
> On Friday, 19 December 2014 at 18:26:26 UTC, MrSmith wrote:
>> The Concise Binary Object Representation (CBOR) is a data format
>> whose design goals include the possibility of extremely small code
>> size, fairly small message size, and extensibility without the need
>> for version negotiation.  These design goals make it different from
>> earlier binary serializations such as ASN.1 and MessagePack.
>>

When implementing CBOR serialization/parsing I got the impression that it was remarkably similar to MessagePack except late. Dis you spot anything different?

On Friday, 19 December 2014 at 22:25:57 UTC, Nordlöw wrote:
> On Friday, 19 December 2014 at 18:26:26 UTC, MrSmith wrote:
>> Here is github link: https://github.com/MrSmith33/cbor-d
>> Destroy!
>
> It would be nice to have a side-by-side comparison with http://msgpack.org/ which is in current use by a couple existing D projects, include D Completion Daemon (DCD) and a few of mine.

There is a comparison to msgpack here (and to other formats too): http://tools.ietf.org/html/rfc7049#appendix-E.2
which states:
   [MessagePack] is a concise, widely implemented counted binary serialization format, similar in many properties to CBOR, although somewhat less regular. While the data model can be used to represent JSON data, MessagePack has also been used in many remote procedure call (RPC) applications and for long-term storage of data.
   MessagePack has been essentially stable since it was first published around 2011; it has not yet had a transition. The evolution of MessagePack is impeded by an imperative to maintain complete backwards compatibility with existing stored data, while only few bytecodes are still available for extension.
   Repeated requests over the years from the MessagePack user community to separate out binary text strings in the encoding recently have led to an extension proposal that would leave MessagePack's "raw" data ambiguous between its usages for binary and text data. The extension mechanism for MessagePack remains unclear.

On Friday, 19 December 2014 at 22:33:57 UTC, BBaz wrote:
> Do you know OGDL ?
>
> http://ogdl.org/
>
> It's currently the more 'appealing' thing to me for serialization.

That is interesting! Is there a D implementation?
Though, it looks like there is not much types of data there.

On Friday, 19 December 2014 at 22:46:14 UTC, ponce wrote:
> On Friday, 19 December 2014 at 22:33:57 UTC, BBaz wrote:
>> On Friday, 19 December 2014 at 18:26:26 UTC, MrSmith wrote:
>>> The Concise Binary Object Representation (CBOR) is a data format
>>> whose design goals include the possibility of extremely small code
>>> size, fairly small message size, and extensibility without the need
>>> for version negotiation.  These design goals make it different from
>>> earlier binary serializations such as ASN.1 and MessagePack.
>>>
>
> When implementing CBOR serialization/parsing I got the impression that it was remarkably similar to MessagePack except late. Dis you spot anything different?

Not much in the sense of implementation, but it has text type, indefinite-length encoding, tags and can be easily extended if needed. I think of it as of better msgpack.

On Saturday, 20 December 2014 at 14:11:56 UTC, MrSmith wrote:
> On Friday, 19 December 2014 at 22:25:57 UTC, Nordlöw wrote:
>> On Friday, 19 December 2014 at 18:26:26 UTC, MrSmith wrote:
>>> Here is github link: https://github.com/MrSmith33/cbor-d
>>> Destroy!
>>
>> It would be nice to have a side-by-side comparison with http://msgpack.org/ which is in current use by a couple existing D projects, include D Completion Daemon (DCD) and a few of mine.
>
> There is a comparison to msgpack here (and to other formats too): http://tools.ietf.org/html/rfc7049#appendix-E.2
> which states:

I suggest to look also at Cap'n Proto, its author was the author of the original
google protobuf, and here [1] you can find some interesting insight about
serialization protocols.

I'm planning an implementation of cap'n proto for D...

Good job, anyway! ;-P

[1] http://kentonv.github.io/capnproto/news/
---
Paolo