<br><br><div class="gmail_quote">On Fri, Jun 4, 2010 at 12:02 PM, Ojan Vafai <span dir="ltr">&lt;<a href="mailto:ojan@chromium.org">ojan@chromium.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig <span dir="ltr">&lt;<a href="mailto:sam.weinig@gmail.com" target="_blank">sam.weinig@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="gmail_quote"><div>After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can.  They both provide information to users that are not generally useful (beyond the &quot;continuous integration/buildbot&quot; use-case which I think is of limited utility) and therefore should not be exposed to the web.</div>


</div></blockquote><div><br></div></div><div>Why is the continuous integration/buildbot use-case of limited utility? Or are you saying that Console.memory doesn&#39;t really support that use-case well? I think we want to make it as easy as possible for complex apps (e.g. email apps, mapping apps, etc.) to care about and monitor memory use. </div>
</div></blockquote><div><br></div><div>I am not saying that this API doesn&#39;t support the continuous integration/buildbot use-case, or support it well, I am saying that I don&#39;t think this is a use case we should be supporting in a web facing API.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">

<div><br></div><div>While I&#39;m not convinced by the utility argument, I do buy the security argument. How would you feel about leaving the code in, but disabling it by default? Then it could be enabled by command-line or via a preference.</div>


<div><br></div><div>That said, I&#39;m OK with rolling back for now given that the code was committed without this discussion actually coming to a conclusion.</div></div></blockquote><div><br></div><div>I would rather we didn&#39;t add more #ifdefs.  Instead, this functionality should be available to native APIs (I believe it already is)</div>
<div><br></div><div>-Sam</div></div>