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

[Sam Weinig]

In general, hassle should not be used as a rationale for API design :).
 Another question ,if the browser has multiple heaps, should it report the
combined memory use by all the heaps or just the heap used by the page the
memory object is coming from?

-Sam

On Sat, May 29, 2010 at 12:48 PM, Mikhail Naganov <mnaganov at chromium.org>wrote:

> You mean I should create an .idl description for it? That's not a
> problem. Using a vanilla JS object just seemed easier to me, because
> adding a new .idl file involves much hassle due to the need of
> registering it in a half dozen project files.
>
> On Sat, May 29, 2010 at 19:44, Sam Weinig <sam.weinig at gmail.com> wrote:
> > Why does this API use a vanilla JS object for the memory object rather
> than
> > an interface as we do with pretty much every other API?
> > -Sam
> >
> >
> > On Fri, May 28, 2010 at 10:50 AM, Mikhail Naganov <mnaganov at chromium.org
> >
> > wrote:
> >>
> >> Greetings, WebKit deveopers,
> >>
> >> As a response to requests from web apps developers, I was intended to
> >> add a simple API for accessing web app's memory consumption, see
> >> https://bugs.webkit.org/show_bug.cgi?id=39646
> >>
> >> The scenario of using this API is as follows:
> >>  - a builbot runs web app's common usage scenarios tests;
> >>  - inside tests, memory usage is recorded via the API proposed;
> >>  - the results are sent to a server (using XHR or a CGI request);
> >>  - server plots nice graphs of memory usage status, bound to the
> >> changes made to the web app;
> >>  - thus, if someone does a change that blows up memory usage,
> >> developers will notice.
> >>
> >> As Sam points out, this change may be fine, but he suggests to make it
> >> accessible only when a browser runs in a special "developer" mode.
> >> This can also be applied to the whole 'console' object.
> >>
> >> Please, share your thoughts on this.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100529/2fc6b1e3/attachment.html>