How not to design a wire protocol

[Eric S. Raymond]

Richard Laager via devel <devel at ntpsec.org>:
> Is microjson something I can dynamically link against, or is it embed only?

There are two parts to a microjson deplyment: the generic microjson runtime,
and a set of application-specific structure initializers you have to declare to
tell the runtime how to parse.  The runtime could be dynamically linked.

I wouldn't always do that. Sometimes - especially when I want the deserializer
to be really tight and light - I'd paste in a copy of the runtime and drop out the
unused features. If, for example, you know that you'll never need array parts,
you can dike out about 40% of the runtime.

What I really ought to do, as noted in previous mail, is turn the library into
a code generator.

> Same question for libjsmn?

libjsmn can be dynamically linked.

> There's an outstanding item on my TODO list to investigate packaging
> libjsmn separately for Debian and modifying ntpsec to dynamically link
> against it. The Debian security team, in general, frowns on embedded
> libraries, as it is a mess if there is a security bug in a library which
> is commonly embedded.

Not reecommended in this case.  It is very very unlikely that instability
in libjsmn will ever require it to change.  I don't think we've ever had
toto touch it.

OTOH, packaging microjson might be a good idea.  As Gary said previously,
it's better value.  As I explained in previous mail.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190307/0a764090/attachment.bin>