On Fri, 2015-05-15 at 15:23 +0200, Lennart Poettering wrote:
> On Thu, 07.05.15 17:47, Pavel Odvody (podv...@redhat.com) wrote:
>
> Hmm, so if I grok this right, then this at's a DOM-like ("object
> model") parser for json, where we previously hat a SAX-like ("stream")
> parser only. What's the rationale for this? Why doesn't the stream
> parser suffice?
>
> I intentionally opted for a stream parser when I wrote the code, and
> that#s actually the primary reason why i roleld my own parser here,
> instead of using some existing library....
> Hmm, I'd call it lexer/tokenizer, since the burden of syntactic analysis is on the user. The parser is actually rather thin wrapper around json_tokenize. Rationale: the v2 manifest (also) contains embedded JSON documents and is itself versioned, so it will change sooner or later. I believe that parsing the manifest, or any "decently" complex JSON document, using the stream parser would yield equal or bigger chunk of code than generic DOM parser + few lines that consume it's API. So to sum it up: 1) Syntactic analysis 2) Maintainability 3) Easier consumption > > Signed-off-by: Pavel Odvody <podv...@redhat.com> > > --- > > src/shared/json.c | 437 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++-- > > src/shared/json.h | 36 +++++ > > 2 files changed, 463 insertions(+), 10 deletions(-) > > > > diff --git a/src/shared/json.c b/src/shared/json.c > > index 45c8ece..00d5fce 100644 > > --- a/src/shared/json.c > > +++ b/src/shared/json.c > > @@ -21,17 +21,173 @@ > > Lennart > -- Pavel Odvody <podv...@redhat.com> Software Engineer - EMEA ENG Developer Experience 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
signature.asc
Description: This is a digitally signed message part
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
