Hi Sam, Can you please look at https://bugs.webkit.org/show_bug.cgi?id=41617 where I'm making memory stats reporting controlled by a preference, and turning it off by default. You are in the CC list but for some reason Bugzilla excluded you from the notification list when I uploaded updated patches.
On Sat, Jun 5, 2010 at 13:24, Mikhail Naganov <mnaga...@chromium.org> wrote: > OK, no problem with rolling it back. My apologies for acting too fast, > I strongly believe in RERO philosophy. > > Can you please provide more info on how native APIs can be used for > reporting memory usage data? That is, how a web app can signal that a > measurement is needed to be taken at a certain point in its code? > > On Fri, Jun 4, 2010 at 23:26, Sam Weinig <sam.wei...@gmail.com> wrote: >> >> >> On Fri, Jun 4, 2010 at 12:02 PM, Ojan Vafai <o...@chromium.org> wrote: >>> >>> On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig <sam.wei...@gmail.com> wrote: >>>> >>>> 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 >>>> "continuous integration/buildbot" use-case which I think is of limited >>>> utility) and therefore should not be exposed to the web. >>> >>> Why is the continuous integration/buildbot use-case of limited utility? Or >>> are you saying that Console.memory doesn'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. >> >> I am not saying that this API doesn't support the continuous >> integration/buildbot use-case, or support it well, I am saying that I don't >> think this is a use case we should be supporting in a web facing API. >>> >>> While I'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. >>> That said, I'm OK with rolling back for now given that the code was >>> committed without this discussion actually coming to a conclusion. >> >> I would rather we didn't add more #ifdefs. Instead, this functionality >> should be available to native APIs (I believe it already is) >> -Sam > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev