Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

decouple matcher from traversal - for streaming filter? #26

Closed
dominictarr opened this issue Sep 23, 2011 · 2 comments
Closed

decouple matcher from traversal - for streaming filter? #26

dominictarr opened this issue Sep 23, 2011 · 2 comments

Comments

@dominictarr
Copy link

would it be possible to decouple the matcher from the traversal,
so that it is possible to use this on objects that are fully created finished yet?

basically, over here Floby/node-json-streams#4 we are working on a streaming JSON parser,

in that process, we are already traversing the object,
would it be possible to call part of this module to select what parts of the stream we are interested in?

I presume you would need something like the root object, the current value, and the current path?

cheers, Dominic

@lloyd
Copy link
Owner

lloyd commented Sep 23, 2011

Yo dominic!

So I designed JSONSelect with streaming in mind. I really am excited to someday build fast as hell native stream filtering on top of yajl. That said, the javascript reference implementation here is a complete implementation of the whole JSONSelect selector language, and it would be difficult to adapt it for stream filtering because it includes constructs that need more context (consider the sibling selector, that requires a complete subtree before it can determine if there's a match or not).

On the bright side, If you check out the docs, JSONSelect level 1 is designed to be easy to implement with minimal context, and should be pretty straightforward to implement in a streaming parser: http://jsonselect.org/#docs/levels

This in fact was going to be my strategy with yajl, to start with level 1, and then incrementally add dynamic buffering to handle cases where level 2 or level 3 selectors are used.

hth!

@lloyd lloyd closed this as completed Sep 23, 2011
@dominictarr
Copy link
Author

okay, interesting,

I should say that I do not intend to implement JSONSelect, but I am
interesting in plugging your implementation into a streaming parser.

basically, I'm generating an event whenever an object is complete, at that
point
the current object, and the path to current object are complete. the stack
of ancestor objects may be uncomplete.

okay, so reading the docs there,
it looks like you would just ignore the level 2 stuff, just resort that T
and U where matched at a given level, then when the parent is complete, you
can do the level 2 checks.

what sort of data structure does a JSONSelect expression compile to, and how
do you process that against the traversal?

On Sat, Sep 24, 2011 at 2:05 AM, Lloyd Hilaiel <
[email protected]>wrote:

Yo dominic!

So I designed JSONSelect with streaming in mind. I really am excited to
someday build fast as hell native stream filtering on top of yajl. That
said, the javascript reference implementation here is a complete
implementation of the whole JSONSelect selector language, and it would be
difficult to adapt it for stream filtering because it includes constructs
that need more context (consider the sibling selector, that requires a
complete subtree before it can determine if there's a match or not).

On the bright side, If you check out the docs, JSONSelect level 1 is
designed to be easy to implement with minimal context, and should be pretty
straightforward to implement in a streaming parser:
http://jsonselect.org/#docs/levels

This in fact was going to be my strategy with yajl, to start with level 1,
and then incrementally add dynamic buffering to handle cases where level 2
or level 3 selectors are used.

hth!

Reply to this email directly or view it on GitHub:
#26 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants