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

[Mikhail Naganov]

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