<div dir="ltr"><div><p><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">On Mon, Sep 23, 2013 at 8:58 AM, Simon MacMullen</span><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px"> wrote:</span><br>


</p><p>&gt; However, I&#39;d be reluctant to merge this; conceptually
it&#39;s very specific to your use case - what if you want to match something
other than up to the first &#39;.&#39;? What if you want to do that on something
other than the resource name?</p><p></p><p>&gt; No, I imagined that. They should though :-)</p></div>Thanks for the feedback. You&#39;re right, the compiler didn&#39;t complain but your way does makes more sense. I&#39;ve updated the gist to reflect the changes if anyone is following along.<div>


<br></div><div>
As for use case specificity, I can see your point. Although, I&#39;m struggling to come up with a case where you would want to use a tokenized version of anything other than name. Assuming name is the only thing that makes sense you could potentially have a new attribute called &#39;prefix_delimiter&#39; which would be sent to the tokens function. If you wanted to add more customization there could be &#39;prefix_depth&#39; as well which controlled how many tokens were returned.</div>



<div><br></div><div>These would be global settings but they do have a parallel to the native user permission regex matching which I think makes sense. Going inline with the logic like you mentioned would be flexible but I&#39;m not sure how helpful it would be to have individual delimiters for different resource types. Delimiters seem like they would be more of a global decision for the entire broker once a proper group name convention was decided on.</div>

</div>