Hi Kevin,
> Am 03.09.2015 um 10:31 schrieb Kevin Sapper <[email protected]>:
>
> 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 <[email protected]>:
> 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 <[email protected]>:
> 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 <[email protected]>:
> 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
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
