[webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)

[Mikhail Naganov]

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 <mnaganov at 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.weinig at gmail.com> wrote:
>>
>>
>> On Fri, Jun 4, 2010 at 12:02 PM, Ojan Vafai <ojan at chromium.org> wrote:
>>>
>>> On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig <sam.weinig at 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
>