Loading ...
Sorry, an error occurred while loading the content.

Re: [json] Is JSON suitable for embedded appl ications?

Expand Messages
  • Mark Joseph
    I don t see the point of using something new for binary data. Clearly this is not JSON. If you have an application that needs an encoding that handles
    Message 1 of 6 , Sep 21, 2011
    View Source
    • 0 Attachment
      I don't see the point of using something new for binary data. Clearly this is not JSON. If you have an application that needs an encoding that handles binary I suggest ASN.1 encoding (which is used by LDAP and SNMP)
      http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One

      ASN.1 handles binary and text data, it is extensible and easy to parse. There are also existing software for it.



      Mark Joseph, Ph.D.
      President
      P6R, Inc
      408-205-0361
      mark@...
      Skype: markjoseph_sc
      _____

      From: Stephan Beal [mailto:sgbeal@...]
      To: json@yahoogroups.com
      Sent: Wed, 21 Sep 2011 13:27:54 -0700
      Subject: Re: [json] Is JSON suitable for embedded applications?






      On Tue, Sep 6, 2011 at 6:30 PM, pozzugno <pozzugno@...> wrote:

      > **
      >
      > Could JSON data format be useful for me? Consider that my C compiler
      > doesn't support malloc()/free() functionalities, but only static and
      > automatic variable allocations. Is there a JSON C implementation suitable
      > for small embedded applications, without malloc()/free() and capable
      > reading/writing without storing the entire configuration in RAM?
      >
      > Any suggestion for other data format?
      >
      It sounds like binary is your best bet, but if you're willing to
      hack/experiment a little...

      i have a portable C89/C99 json library (
      http://whiki.wanderinghorse.net/wikis/cson/) which, with only minor changes,
      could use a custom allocator. i also just happen to have a custom allocator
      (http://fossil.wanderinghorse.net/repos/whalloc/index.cgi/wiki/whalloc_bt)
      which
      allows clients to give it a chunk of static (or otherwise-allocated) memory
      for it to malloc/realloc/free from (it was designed for _small_ apps which
      cannot/do not want to call malloc()). With that combination (again, with a
      small amount of hacking), if you know the approximate memory requirements in
      advance and you can spare it, i think it would work. You could also test it
      without your embedded device, and tweak/optimize the memory parameters, by
      using the same static memory block size on a dev environment. If you're
      interested in trying that out, send me your rough memory limits (off list:
      sgbeal googlemail com) and i'll see if i can throw it together. i can't
      guaranty it would work without a single malloc(), but (A) i think it could
      and (B) it might be fun to try. cson is fairly heavily optimized for a
      minimal number of calls to malloc(), that being an explicit design goal.

      i would also recommend looking at the jansson C library, but if i'm not
      sorely mistaken, cson is better optimized for low memory consumption.
      jansson supports, e.g., handling of cyclic structures, and that inherently
      adds memory costs. jansson also allows mutation of values after creating
      them, which (if i'm not mistaken) implicitly precludes certain pedantic
      malloc() reduction optimizations which cson does (i had to remove the
      mutator functions from the public API in order to be able to make some of
      those optimizations).

      --
      ----- stephan beal
      http://wanderinghorse.net/home/stephan/

      [Non-text portions of this message have been removed]




      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.