<br><br><div class="gmail_quote">On Tue, Mar 26, 2013 at 11:44 AM, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo.niemeyer@canonical.com" target="_blank">gustavo.niemeyer@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Mar 26, 2013 at 3:32 PM, Kapil Thangavelu<br>
<<a href="mailto:kapil.thangavelu@canonical.com">kapil.thangavelu@canonical.com</a>> wrote:<br>
</div><div class="im">> afaics the best way to ensure this divergence doesn't happen is to use the<br>
> go charm definition for validation of a charm and incorporate that into<br>
> charm-lint/charm browser, or alternatively to put an interface on the charm<br>
> store to collect the errors for a given charm branch there.<br>
<br>
</div>No, the best way to ensure this divergence doesn't happen is to check<br>
the store to see if a charm exists. This is very trivial to do, and<br>
very effective too. Anything else will open the door for headaches.<br>
<div class="im"></div></blockquote><div><br></div><div>The charm browser does do this check and stores it against the charm although its not currently limiting visibility on this alone. It should do that though (bug 1160527). The issue is that we have no feedback mechanism for users from the store, so at times it can be opaque as to what the actual issue is with the appearance in the charm store, unless that rule is also encoded into the charm-lint tool, or into the review queue/lint reports on the browser. The mechanism i suggested was to avoid this divergence of rules  by incorporating the store processing directly into the feedback mechanisms we have for charm authors.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> incidentally the mongodb issue is a pymongo driver thing, previous versions<br>
> of the driver where able to handle '.' in values without issue.<br>
<br>
</div>There's more to it than that. The dot is used in several places in<br>
MongoDB to define sub-document access.<br></blockquote><div><br></div><div>indeed, and that was likely the cause for the driver change to remove ambiguity, but it also implies mongodb can handle such values.</div><div><br>
</div><div>cheers,</div><div><br></div><div>Kapil</div></div>