From: Oleksandr Gavenko <gavenkoa@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Look for data serialisation format to implement communication between Emacs and external program.
Date: Mon, 07 Jan 2013 15:53:57 +0200 [thread overview]
Message-ID: <87wqvprte2.fsf@gavenkoa.example.com> (raw)
In-Reply-To: m2wqvpig3l.fsf@gmail.com
On 2013-01-07, Helmut Eller wrote:
> On Sun, Jan 06 2013, Oleksandr Gavenko wrote:
>
>> Is that right to use ASN.1 BER as serialisation data format for communication
>> between Emacs and external program?
>
> S-expressions is the only format that Emacs can write and parse quickly
> because the printer and reader are implemented in C. This is likely 10
> times faster than any parser that you write in Emacs Lisp. The downside
> is that the external program needs to be able to do the same. Not such
> a bad tradeoff as S-expressions are fairly easy to parse.
>
> For communication with an external format I recommend a "framed" format:
> a frame is a fixed sized header followed by a variable length payload.
> The header describes the length of the frame. The length should be in
> bytes (not characters as counting characters in UTF8 strings is
> uneccessary complicated). Knowing the length of the frame is very
> useful because that makes it easy to wait for a complete frame. After
> you received a complete frame, parsing is simpler because you don't have
> to worry about incomplete input.
>
> I also recommend to limit the frame length to 24 bits (not 32 bit)
> because Emacs fixnums are limited to 29 bits on 32 bit machines.
>
> The payload can then be an S-expression printed with the Emacs prin1 and
> parsed back with the read function. The encoding of the payload can be
> utf-8. But use the Emacs 'binary coding system for communication with
> the external process and unibyte buffers for parsing. For the
> binary-to-utf8 conversion of the payload use something like
> decode-coding-string (which is written C and should be fast).
>
Seems that this is good solution in case of Emacs:
(assoc ':title (read "((:type blog-entry) (:title \"Hello\") (:article \"world!\"))"))
Data validation:
(read ")") ;; ==> invalid-read-syntax
or when assoc return unknown ":type", etc...
Only things that annoying is escaping (like <div>hello</div> for
<div>hello</div> in XML or in SLIP protocol where 0x7e escaped by 0x7d 0x5e
and escape character 0x7d escaped by 0x7d 0x5d).
> If you like, you can also use extra bits in the header to indicate the
> format of the payload. E.g. it might be useful to have frames that
> contain only plain strings (not encoded as S-expr).
>
I start from using custom TLV data format but parsing and validation is hand
written so I decide as for suggestions...
--
Best regards!
next prev parent reply other threads:[~2013-01-07 13:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.16821.1357508702.855.help-gnu-emacs@gnu.org>
2013-01-07 7:53 ` Look for data serialisation format to implement communication between Emacs and external program Helmut Eller
2013-01-07 13:53 ` Oleksandr Gavenko [this message]
2013-01-06 21:44 Oleksandr Gavenko
2013-01-06 22:46 ` Thien-Thi Nguyen
2013-01-07 13:35 ` Oleksandr Gavenko
2013-01-08 9:44 ` Thien-Thi Nguyen
2013-01-07 21:57 ` Oleksandr Gavenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wqvprte2.fsf@gavenkoa.example.com \
--to=gavenkoa@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).