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

[Patrick Mueller]

On 6/5/10 5:24 AM, Mikhail Naganov wrote:

> 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?

For a specific example, today, you can use console.markTimeline(message) 
to have an entry added to the debug time line.  May not be the 
measurement you were looking for ... :-)

But this raises a distinction - it's probably ok to allow functions like 
console.markTimeline(message) (and any other sort of diagnostic related 
function) as long as they don't actually do anything unless you are 
debugging.  It's not clear to me that's the case today for 
markTimeline(), nor whether it's a problem if it actually does do 
something if you aren't debugging - all of the console APIs probably 
need to be looked at.

> 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.

I talked to a developer a few months ago that was building a system to 
collect profiling information in an 'as automated fashion as possible'. 
  He wanted to collect the information over time for analysis.  Makes 
sense to me.  I believe he was using console.profiles() for this - 
across FireBug and WebKit.  This was all user-land code; they were 
collecting the information and uploading it back to their site for later 
analysis.  Use Case!

You could argue this can be solved by "tools", but as someone who has 
been in the "tools vendor" business for a long time, I can tell you if 
your answer is "you just need tools", you're not going far enough. 
Smart developers prefer APIs so they can build their own tools.

I agree we need to secure this stuff, it is obviously not of interest to 
 > 99.99% of the end users of WebKit, but it's invaluable to the 0.01% 
out there.  If we found a way to secure this, could we use a pattern of 
adding APIs like console.profiles() secured by that mechanism?

As for the use case above, the app collecting the information was a 
specially built application used only by developers.  I suspect they'd 
be willing to deal with any extra overhead or ickiness in allowing this 
secured use, assuming it could eventually be automated.

-- 
Patrick Mueller - http://muellerware.org