Re: [chromium-dev] Process Model Extension API Proposal
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.orgwrote: 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? This would be fairly easy to support. You can just observe NotificationType::RENDERER_PROCESS_HANG. -Darin 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 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 --
Re: [chromium-dev] Process Model Extension API Proposal
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? 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 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
Re: [chromium-dev] Process Model Extension API Proposal
On Fri, Jan 15, 2010 at 12:04 PM, Rafael Weinstein rafa...@chromium.orgwrote: 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? 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 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
Re: [chromium-dev] Process Model Extension API Proposal
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:
Re: [chromium-dev] Process Model Extension API Proposal
On Fri, Jan 15, 2010 at 1:33 PM, Rafael Weinstein rafa...@chromium.orgwrote: 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() Makes sense-- it's easy it get the processId from the Process object if that's what you want. I added it to the doc, along with a new onUnresponsive event (rather than onHung). Charlie 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
Re: [chromium-dev] Process Model Extension API Proposal
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? 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.comwrote: 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.orgwrote: 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.orgwrote: 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
Re: [chromium-dev] Process Model Extension API Proposal
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.comwrote: 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.orgwrote: 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.orgwrote: 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
Re: [chromium-dev] Process Model Extension API Proposal
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
Re: [chromium-dev] Process Model Extension API Proposal
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'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 On Tue, Jan 12, 2010 at 12:38 PM, Matt Perry mpcompl...@chromium.orgwrote: 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
Re: [chromium-dev] Process Model Extension API Proposal
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.orgwrote: 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.orgwrote: 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
Re: [chromium-dev] Process Model Extension API Proposal
(re-sending from chromium address) 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?), Yes, since yesterday (at least most of it). Note that some of the memory columns might be win-specific (they are always 0 on linux, I haven't yet looked at if they can be computed on OS X), so don't just expose every column in an extension api without checking if it works cross-platform. so it seems like a decent idea to let extensions reuse the work done rather than reimplementing everything. 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 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
Re: [chromium-dev] Process Model Extension API Proposal
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.comwrote: 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.orgwrote: 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.orgwrote: 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
