<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 15, 2013, at 5:28 AM, Phil Mayers <<a href="mailto:p.mayers@imperial.ac.uk">p.mayers@imperial.ac.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 06/15/2013 12:13 PM, Glyph wrote:<br><br><blockquote type="cite">I am really, really puzzled by this reaction. I am wondering if you<br>read my message carefully, or if I didn't express myself well.<br></blockquote><br>Careful re-reading of the very last bit of your message suggests I may have misunderstood.<br></div></blockquote><div dir="auto"><br></div><div dir="auto">OK, whew :).</div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I think I understand the "final" stage, and in that situation the UUID is invisible, correct? It's hidden behind the declaration of a "log event" object which can be called to emit or observe said events.</div></blockquote><div dir="auto"><br></div><div dir="auto">That's right.</div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">That seems fine, though I'm not sure what the UUID *does* in that situation - route/match is via python object access, no?<br></div></blockquote><div dir="auto"><br></div><div dir="auto">What it does is it allows *older* monitoring scripts to work. It also holds on to the UUID internally so that if, for example, the module's name is changed in the future, the API name can be re-named and code can be pointed at it via the normal deprecate/redirect mechanism. (Of course, _any_ sort of explicit / unique identifier would work for this latter use-case; it's just that this one has the benefit of not visibly containing the string that has now been changed, and so there's no long-term impulse to "clean it up" further and thus break stuff.)</div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I *think* I now understand the intermediate stage, where the log events are emitted by old code, and observed by UUID. You're suggesting calculating the UUID from the module name and static data (format string). I guess that's no worse than any other solution - until the log emitter is converted to a newer/better API, there's no great way to observe it.<br></div></blockquote><div><br></div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Before we proceed, can you confirm I've understood your proposal correctly?<br></div></blockquote><br></div><div>Sounds like you've got it just about right now.</div><div><br></div><div>-g</div></body></html>