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.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.
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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
