[zeromq-dev] subtree matching with ztrie (#1073)

Michael Haberler mail17 at mah.priv.at
Thu Sep 3 12:10:03 CEST 2015


Hi Kevin,

> Am 03.09.2015 um 10:31 schrieb Kevin Sapper <kevinsapper88 at gmail.com>:
> 
> I'm really sorry for the spam :( This stupid gmail client is killing me.
> 
> Hi Michael,
> 
> your use case is currently not possible with ztrie as it cannot handle routes of variable length. The current implementation only compares token which are on the same level in the tree and a regular expression can only be used to match one token of the same level. 
> 
> For example the route '/config/redis/{[^/]+}' matched against '/config/redis/foo/bar/baz' will match
> 
>   config => config
>   redis => redis
>   [^/]+ => foo
> 
> and then abort with a mismatch as the inserted route does not contain one more tokens.
> 
> However I think your use case is valid, but I like to make some limitations to the star operator:

(I guess the star is in the pipe - I am delighted ;)


> 
>   -  If the star operator is used, no other route can have children with the common prefix
>     
>     ztrie_insert_route ('/config/redis/*') => valid
>     ztrie_insert_route ('/config/redis/foo') => invalid
>   
>   OR
> 
>     ztrie_insert_route ('/config/redis/foo') => valid
>     ztrie_insert_route ('/config/redis/*') => invalid

At least for this use case this looks fine, as I'd use '/config/redis/*' ff merely as a mount point detection vehicle

storing/retrieval below that mount point will not go through ztrie_insert_route() but be passed on to the plugin which is called once the mount point is traversed

the only requirement I have is - if I do ztrie_matches('/config/redis/foo/bar/baz...') I need to get at the 'foo/bar/baz...' key path one way or the other to continue in the plugin



thinking of it - an idea: actually something like a soft link might be very useful for flexibly structuring a namespace without hard-coding:

- devise a way of associating a route with another one, like ztrie_alias_route('/config/ini', '/config/zconfig')
- thereafter, ztrie_matches('/config/ini/foo/bar/baz...') would actually resolve to ztrie_matches('/config/zconfig/foo/bar/baz...') 

but that's already icing on the cake

thanks - that looks very promising!

best regards

Michael


> 
> //Kevin
> P.S: Sorry again for the spamming.
> 
> 2015-09-03 10:26 GMT+02:00 Kevin Sapper <kevinsapper88 at gmail.com>:
> Sorry I didn't mean to send the first message, somehow my gmail got crazy.
> 
> Hi Michael,
> 
> your use case is currently not possible with ztrie as it cannot handle routes of variable length. The current implementation only compares token which are on the same level in the tree and a regular expression can only be used to match one token of the same level. 
> 
> For example the route '/config/redis/{[^/]+}' matched against '/config/redis/foo/bar/baz' will match
> 
>   config => config
>   redis => redis
>   [^/]+ => foo
> 
> and then abort with a mismatch as the inserted route does not contain one more tokens.
> 
> However I think your use case is valid, but I like to make some limitations to the star operator:
> 
>   -  If the star operator is used, no other route can have children with the common prefix
>     
>     ztrie_insert_route ('/config/redis/*') => valid
>     ztrie_insert_route ('/config/redis/foo') => invalid
>   
>   OR
> 
>     ztrie_insert_route ('/config/redis/foo') => valid
> 
> 
> 2015-09-03 10:22 GMT+02:00 Kevin Sapper <kevinsapper88 at gmail.com>:
> Hi Michael,
> 
> your use case is currently not possible with ztrie as it cannot handle routes of variable length. The current implementation only compares token which are on the same level in the tree and a regular expression can only be used to match one token of the same level. 
> 
> For example the route '/config/redis/{[^/]+}' matched against '/config/redis/foo/bar/baz' will match
> 
>   config => config
>   redis => redis
>   [^/]+ => foo
> 
> and then abort with a mismatch as the inserted route does not contain one more tokens.
> 
> However I think your use case is valid but I like to make some limitations to the star operator:
> 
>   -  If the star operator is used, no other route can have children with the common prefix
>     '/config/redis/*' (valid)
> 
> 
> 
> 
> 2015-09-02 14:24 GMT+02:00 Michael Haberler <mail17 at mah.priv.at>:
> I like the ztrie idea from #1073!  I'm considering this use case: *)
> 
> server-side you'd insert routes like
> 
>   /config/redis/*
>   /config/zconfig/*
>   /config/init/*
> 
> and associate a match of /config/<method>/ with what is essentially a vtable which knows how to handle that subtree type
> 
> client-side operations would be roughly so:
> 
>   lookup(/config/redis/<some path of length > 0>)
>   set(/config/redis/<some path of length > 0>/<value>)
>   subscribe(/config/redis/<some path of length > 0>, change_callback)
> 
> I guess what I need is a way to store the routes as above, plus a match method which would
> 
> given say "/config/redis/foo/bar/baz" :
> 
> - yield the data for /config/redis (i.e. the redis methods vtable)
> - plus "foo/bar/baz" (as string or in tokenized 'ztrie_hit_parameters)' form)
> 
> how would I do that? I am unclear how to match a (possibly indefinite length) number of route elements.
> 
> thanks!
> 
> - Michael
> 
> 
> *) a zeromq-based networked configuration store "borrowing with pride" from  zookeeper/etcd/webdis/augeas/libelektra - a tree-structure key/value space (but a tad less filling than those examples)
>  with a 'mount some method into the tree at a given point' capability to integrate various configuration sources (some of them legacy like INI files, or redis, or zconfig - maybe based on plugins)
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




More information about the zeromq-dev mailing list