On Fri, Jan 15, 2010 at 1:27 PM, Charlie Reis <cr...@chromium.org> wrote:
>
>
> On Fri, Jan 15, 2010 at 12:04 PM, Rafael Weinstein <rafa...@chromium.org>
> wrote:
>>
>> LGTM also.
>>
>> One thought: I've seen a few requests on the crx-dev mailing list for
>> API capabilities for both finding out when a process has crashed and
>> also when it has become unresponsive. I'm unfamiliar with our code
>> that checks for a hung renderer. Would the process.cpu value be a
>> proxy for this? Would there be another way to expose it?
>
> I have the onExited event to listen for crashed tabs.
> For hung tabs, I don't think cpu is a good proxy for it. Maybe we could add
> a onHung event that fires when Chrome decides a process is unresponsive?
Sounds good.
>>
>> Also, my preference would be for avoiding adding processId to Tab and
>> using processes.get(tabId) instead, just for the sake of keeping the
>> API completely contained within the experimental namespace.
>>
>> R
>
> Darn, I was just getting ready to submit that CL for review. :)
> I'd like to still pass a process ID to the get() method, so that it can be
> useful for browser, plugin, and renderer processes as well. Maybe
> chrome.experimental.processes.getProcessId(tabId), with the expectation that
> it will be removed when processId is later added to Tab?
> Charlie
Sorry, I didn't noticed that get() was taking a processId (duh).
Sound good. Or even getProcessForTab(tabId), just because it's most
likely you'll just turn around and call processes.get() on the result
of getProcessId()
>
>
>>
>> On Wed, Jan 13, 2010 at 2:49 PM, Erik Kay <erik...@chromium.org> wrote:
>> > On Wed, Jan 13, 2010 at 1:21 PM, Charlie Reis <cr...@chromium.org>
>> > wrote:
>> >>
>> >> Thanks. I've updated the proposal doc based on suggestions from this
>> >> discussion, including a global onUpdated event, notes about only
>> >> providing
>> >> cross-platform statistics, and adding a tabs array to each Process for
>> >> the
>> >> tabs associated with it (at least for renderer processes).
>> >> http://docs.google.com/View?id=dhr988kp_4f76886hc
>> >> As Aaron mentions, most of this can start out in the
>> >> chrome.experimental
>> >> namespace. I'd like to add the processId property to Tab, which has
>> >> value
>> >> on its own without the rest of the chrome.experimental.processes
>> >> module.
>> >> (e.g., I used it to build the first example use case: a Browser Action
>> >> that
>> >> shows all the tabs sharing the current tab's process.) Can I add that
>> >> property to Tab directly, or should I temporarily add an experimental
>> >> API to
>> >> get a processId given a tabId?
>> >
>> > Yeah, unfortunately we don't have a way of adding experimental fields to
>> > non-experimental APIs. In this case, I'd say processId is a relatively
>> > safe
>> > addition, so go for it.
>> > Erik
>> >
>> >>
>> >> Charlie
>> >>
>> >>
>> >> On Tue, Jan 12, 2010 at 5:09 PM, Erik Kay <erik...@chromium.org> wrote:
>> >>>
>> >>> LGTM.
>> >>> I agree that you should look into the broad (global, not per-process)
>> >>> onUpdated event. For any active monitoring extension (vs. static
>> >>> display),
>> >>> I would wager that this would result in a more efficient
>> >>> implementation than
>> >>> having them poll.
>> >>> I also agree with Aaron's answers to your open questions.
>> >>> Erik
>> >>>
>> >>> On Tue, Jan 12, 2010 at 1:08 PM, Charlie Reis <cr...@chromium.org>
>> >>> wrote:
>> >>>>
>> >>>> On Tue, Jan 12, 2010 at 12:44 PM, James Robinson <jam...@google.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Getting this information in a cross-platform way is a huge pain (do
>> >>>>> we
>> >>>>> even do it properly for mac yet?), so it seems like a decent idea to
>> >>>>> let
>> >>>>> extensions reuse the work done rather than reimplementing
>> >>>>> everything.
>> >>>>
>> >>>> I agree. Plus NPAPI "is a really big hammer" that throws out most of
>> >>>> the protections that Chromium's process model and sandbox offer
>> >>>> extensions,
>> >>>> so I'd find it ironic to rely on that for people interested in data
>> >>>> about
>> >>>> the process model...
>> >>>>
>> >>>>>
>> >>>>> I'd suggest having the browser fire some sort of update event to the
>> >>>>> extension whenever the metrics are updated rather than forcing the
>> >>>>> extension
>> >>>>> to poll. This is how the task manager works currently.
>> >>>>>
>> >>>>> - James
>> >>>>
>> >>>> I'm happy to add an onUpdated event, but I thought it might be fired
>> >>>> too
>> >>>> often to expose it as an extension event. If we're not concerned
>> >>>> about the
>> >>>> frequency, I'll put it in the proposal.
>> >>>> Charlie
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> On Tue, Jan 12, 2010 at 12:38 PM, Matt Perry
>> >>>>> <mpcompl...@chromium.org>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> Would it be possible to implement the same functionality using an
>> >>>>>> NPAPI plugin? Extensions are allowed to bundle native plugins and
>> >>>>>> interact
>> >>>>>> with them from script.
>> >>>>>> On Tue, Jan 12, 2010 at 10:48 AM, Charlie Reis <cr...@chromium.org>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> Hi folks--
>> >>>>>>> I've put together a proposal for a Chromium extensions module
>> >>>>>>> that
>> >>>>>>> exposes
>> >>>>>>> data about the browser's processes. I think this could be useful
>> >>>>>>> for
>> >>>>>>> things
>> >>>>>>> like per-tab CPU/memory utilization graphs, custom task managers,
>> >>>>>>> or
>> >>>>>>> visualizing which tabs are sharing processes.
>> >>>>>>> http://docs.google.com/View?id=dhr988kp_4f76886hc
>> >>>>>>> Please let me know what you think.
>> >>>>>>> Thanks!
>> >>>>>>> Charlie Reis
>> >>>>>>> --
>> >>>>>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> >>>>>>> View archives, change email options, or unsubscribe:
>> >>>>>>> http://groups.google.com/group/chromium-dev
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> >>>>>> View archives, change email options, or unsubscribe:
>> >>>>>> http://groups.google.com/group/chromium-dev
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> >>>> View archives, change email options, or unsubscribe:
>> >>>> http://groups.google.com/group/chromium-dev
>> >>>
>> >>
>> >
>> >
>> > --
>> > Chromium Developers mailing list: chromium-dev@googlegroups.com
>> > View archives, change email options, or unsubscribe:
>> > http://groups.google.com/group/chromium-dev
>> >
>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
