Re: [chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
(and again from right address) Since snej is writing a native bookmark manager on OS X that is done this week from what I understand, it seems like there is no need for a rush here. If you think the more involved solution is better, it might be worth doing. On Tue, Dec 15, 2009 at 8:01 AM, Nico Weber wrote: > Since snej is writing a native bookmark manager on OS X that is done > this week from what I understand, it seems like there is no need for a > rush here. If you think the more involved solution is better, it might > be worth doing. > > On Tue, Dec 15, 2009 at 7:28 AM, Erik Kay wrote: >> On Mon, Dec 14, 2009 at 6:24 PM, Aaron Boodman wrote: >>> >>> On Mon, Dec 14, 2009 at 5:43 PM, Erik Kay wrote: >>> > On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman wrote: >>> >> >>> >> Seems like a bad idea. >>> >> >>> >> Extensions and DOMUI are basically two competing systems for doing the >>> >> same thing, it would get confusing combining them. >>> > >>> > While I can see this in principle, I'm not sure I see what the problems >>> > are >>> > in practice. What kinds of problems do you envision? >>> > I think it would be nice for our current DOMUI pages to be built on top >>> > of >>> > the extensions APIs, but potentially have access to a few special APIs >>> > that >>> > extensions don't. It seems like it would be painful to try to cut them >>> > over >>> > to such a system all at once, so adding extensions APIs to DOMUI pages >>> > could >>> > be a nice bridge. >>> >>> When you say "built on top of the extensions APIs" do you mean have >>> access to, eg, chrome.tabs.*? >> >> I'm more interested in this aspect in the short term, and I think this is >> what would most help arv in the short term as well. Regardless of how the >> dispatch system works, even the APIs themselves are there, we're more likely >> to be able to migrate the existing pages to use the same APIs. >> >>> >>> Or do you mean use our >>> ExtensionFunctionDispatcher and json schema infrastructure, but not >>> use any of our APIs? >> >> I think it would be cool to do this as well, but more from the standpoint >> that it would then be more straightforward for new APIs to be added and >> supported that could be used in both places. >> >>> >>> I looked at the latter once before and it was a >>> serious project. There is a lot of knowledge about the extension >>> system baked into ExtensionFunctionDispatcher, such as who the current >>> extension is and knowledge of the json schema system in the renderer. >>> >>> I think a simpler approach to get the benefits of the extension system >>> is to just make the bookmark manager an extension. We'd have to filter >>> it out of the chrome://extensions/ page and change its icon in the >>> task manager, but those are fairly trivial changes compared to tearing >>> all the knowledge of extensions out of ExtensionFunctionDispatcher >>> system. >>> >>> If we want the bookmark manager to have some special APIs that other >>> extensions don't, that also seems fairly easy to do once the bookmark >>> manager is indeed an extension. >>> >>> To be clear, I'm also open to lower-level refactorings. I'm just >>> warning that I suspect it's a serious project. A couple weeks at >>> least. >> >> Yeah, I can imagine that. It sounds like Erik's needs are shorter term than >> would warrant this kind of approach. >> Erik >> >>> >>> - a >> >> -- >> 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-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 6:24 PM, Aaron Boodman wrote: > On Mon, Dec 14, 2009 at 5:43 PM, Erik Kay wrote: > > On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman wrote: > >> > >> Seems like a bad idea. > >> > >> Extensions and DOMUI are basically two competing systems for doing the > >> same thing, it would get confusing combining them. > > > > While I can see this in principle, I'm not sure I see what the problems > are > > in practice. What kinds of problems do you envision? > > I think it would be nice for our current DOMUI pages to be built on top > of > > the extensions APIs, but potentially have access to a few special APIs > that > > extensions don't. It seems like it would be painful to try to cut them > over > > to such a system all at once, so adding extensions APIs to DOMUI pages > could > > be a nice bridge. > > When you say "built on top of the extensions APIs" do you mean have > access to, eg, chrome.tabs.*? I'm more interested in this aspect in the short term, and I think this is what would most help arv in the short term as well. Regardless of how the dispatch system works, even the APIs themselves are there, we're more likely to be able to migrate the existing pages to use the same APIs. > Or do you mean use our > ExtensionFunctionDispatcher and json schema infrastructure, but not > use any of our APIs? I think it would be cool to do this as well, but more from the standpoint that it would then be more straightforward for new APIs to be added and supported that could be used in both places. > I looked at the latter once before and it was a > serious project. There is a lot of knowledge about the extension > system baked into ExtensionFunctionDispatcher, such as who the current > extension is and knowledge of the json schema system in the renderer. > > I think a simpler approach to get the benefits of the extension system > is to just make the bookmark manager an extension. We'd have to filter > it out of the chrome://extensions/ page and change its icon in the > task manager, but those are fairly trivial changes compared to tearing > all the knowledge of extensions out of ExtensionFunctionDispatcher > system. > > If we want the bookmark manager to have some special APIs that other > extensions don't, that also seems fairly easy to do once the bookmark > manager is indeed an extension. > > To be clear, I'm also open to lower-level refactorings. I'm just > warning that I suspect it's a serious project. A couple weeks at > least. > Yeah, I can imagine that. It sounds like Erik's needs are shorter term than would warrant this kind of approach. Erik > > - a > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 18:24, Aaron Boodman wrote: > On Mon, Dec 14, 2009 at 5:43 PM, Erik Kay wrote: >> On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman wrote: >>> >>> Seems like a bad idea. >>> >>> Extensions and DOMUI are basically two competing systems for doing the >>> same thing, it would get confusing combining them. >> >> While I can see this in principle, I'm not sure I see what the problems are >> in practice. What kinds of problems do you envision? >> I think it would be nice for our current DOMUI pages to be built on top of >> the extensions APIs, but potentially have access to a few special APIs that >> extensions don't. It seems like it would be painful to try to cut them over >> to such a system all at once, so adding extensions APIs to DOMUI pages could >> be a nice bridge. > > When you say "built on top of the extensions APIs" do you mean have > access to, eg, chrome.tabs.*? Or do you mean use our > ExtensionFunctionDispatcher and json schema infrastructure, but not > use any of our APIs? I looked at the latter once before and it was a > serious project. There is a lot of knowledge about the extension > system baked into ExtensionFunctionDispatcher, such as who the current > extension is and knowledge of the json schema system in the renderer. > > I think a simpler approach to get the benefits of the extension system > is to just make the bookmark manager an extension. We'd have to filter > it out of the chrome://extensions/ page and change its icon in the > task manager, but those are fairly trivial changes compared to tearing > all the knowledge of extensions out of ExtensionFunctionDispatcher > system. > > If we want the bookmark manager to have some special APIs that other > extensions don't, that also seems fairly easy to do once the bookmark > manager is indeed an extension. > > To be clear, I'm also open to lower-level refactorings. I'm just > warning that I suspect it's a serious project. A couple weeks at > least. The goal is to have a working bookmark manager at the end of January and a complete one at the end of Q1. That makes me think that making a DOM UI version that uses the extension API would not be feasible. I also don't think that doing it as an extension is something that can be done in the same time frame due to lacking APIs. I think I'll just do an old school DOM UI and emulate the extensions bookmark API so that the same code can be used. > > - a > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 5:43 PM, Erik Kay wrote: > On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman wrote: >> >> Seems like a bad idea. >> >> Extensions and DOMUI are basically two competing systems for doing the >> same thing, it would get confusing combining them. > > While I can see this in principle, I'm not sure I see what the problems are > in practice. What kinds of problems do you envision? > I think it would be nice for our current DOMUI pages to be built on top of > the extensions APIs, but potentially have access to a few special APIs that > extensions don't. It seems like it would be painful to try to cut them over > to such a system all at once, so adding extensions APIs to DOMUI pages could > be a nice bridge. When you say "built on top of the extensions APIs" do you mean have access to, eg, chrome.tabs.*? Or do you mean use our ExtensionFunctionDispatcher and json schema infrastructure, but not use any of our APIs? I looked at the latter once before and it was a serious project. There is a lot of knowledge about the extension system baked into ExtensionFunctionDispatcher, such as who the current extension is and knowledge of the json schema system in the renderer. I think a simpler approach to get the benefits of the extension system is to just make the bookmark manager an extension. We'd have to filter it out of the chrome://extensions/ page and change its icon in the task manager, but those are fairly trivial changes compared to tearing all the knowledge of extensions out of ExtensionFunctionDispatcher system. If we want the bookmark manager to have some special APIs that other extensions don't, that also seems fairly easy to do once the bookmark manager is indeed an extension. To be clear, I'm also open to lower-level refactorings. I'm just warning that I suspect it's a serious project. A couple weeks at least. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman wrote: > Seems like a bad idea. > > Extensions and DOMUI are basically two competing systems for doing the > same thing, it would get confusing combining them. While I can see this in principle, I'm not sure I see what the problems are in practice. What kinds of problems do you envision? I think it would be nice for our current DOMUI pages to be built on top of the extensions APIs, but potentially have access to a few special APIs that extensions don't. It seems like it would be painful to try to cut them over to such a system all at once, so adding extensions APIs to DOMUI pages could be a nice bridge. Erik > I would rather > either: > > a) add new (possibly experimental) APIs for the issues you've run into. > b) manually plumb the extension APIs you need through DOMUI (this is > basically composition instead of inheritance) > > Is this the complete list of bugs? > > http://code.google.com/p/chromium/issues/list?can=2&q=feature:extensions+reporter:arv > > Context menu is potentially on the M5 list. Depending on how complex a > context menu API you want, this might not be too bad. We should just > implement the chrome:// urls one I guess. > > - a > > On Mon, Dec 14, 2009 at 3:36 PM, Erik Arvidsson wrote: > > I'm in the process of writing a bookmark manager in HTML. So far I've > > written it as an extension but I'm now considering changing this to a > > DOM UI page instead. [*] > > > > I would like to be able to expose the extensions API for bookmarks to > > the DOM UI (and eventually make all DOM UI pages use extension APIs). > > Where do I start? Is this a bad idea? > > > > Another option is to keep the bookmarks manager as a special extension > > that is always turned on. > > > > [*] Extensions do not have enough privileges and there aren't enough > > hooks to allow extensions to do all the things the bookmark manager > > needs to do. I've filed bugs for everything I've run into. > > > > erik > > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 5:29 PM, Erik Arvidsson wrote: > On Mon, Dec 14, 2009 at 16:48, Aaron Boodman wrote: >> Seems like a bad idea. >> >> Extensions and DOMUI are basically two competing systems for doing the >> same thing, it would get confusing combining them. I would rather >> either: >> >> a) add new (possibly experimental) APIs for the issues you've run into. >> b) manually plumb the extension APIs you need through DOMUI (this is >> basically composition instead of inheritance) > > Seems like b then. However, the extensions APIs are much nicer than > all the ad-hoc chrome.send + CallJavascriptFunction we are currently > using and having the same API seems like a win for maintainability. I agree the current DOM UI method of sending calls stinks. I've looked at using the extension system's mechanism before but it will be a lot of work to decouple from the extension system I think. But feel free to take a fresh look if you want. >> Is this the complete list of bugs? >> http://code.google.com/p/chromium/issues/list?can=2&q=feature:extensions+reporter:arv >> >> Context menu is potentially on the M5 list. Depending on how complex a >> context menu API you want, this might not be too bad. We should just >> implement the chrome:// urls one I guess. > > If we make the bookmark manager completely as an extension extensions > need to be able to hook up global keyboard shortcuts (27702) as well > as some way to hook into the wrench and system menus on mac. I don't see why. We can implement those things in Chrome directly. Chrome can know about this special extension. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 16:48, Aaron Boodman wrote: > Seems like a bad idea. > > Extensions and DOMUI are basically two competing systems for doing the > same thing, it would get confusing combining them. I would rather > either: > > a) add new (possibly experimental) APIs for the issues you've run into. > b) manually plumb the extension APIs you need through DOMUI (this is > basically composition instead of inheritance) Seems like b then. However, the extensions APIs are much nicer than all the ad-hoc chrome.send + CallJavascriptFunction we are currently using and having the same API seems like a win for maintainability. > > Is this the complete list of bugs? > http://code.google.com/p/chromium/issues/list?can=2&q=feature:extensions+reporter:arv > > Context menu is potentially on the M5 list. Depending on how complex a > context menu API you want, this might not be too bad. We should just > implement the chrome:// urls one I guess. If we make the bookmark manager completely as an extension extensions need to be able to hook up global keyboard shortcuts (27702) as well as some way to hook into the wrench and system menus on mac. > > - a > > On Mon, Dec 14, 2009 at 3:36 PM, Erik Arvidsson wrote: >> I'm in the process of writing a bookmark manager in HTML. So far I've >> written it as an extension but I'm now considering changing this to a >> DOM UI page instead. [*] >> >> I would like to be able to expose the extensions API for bookmarks to >> the DOM UI (and eventually make all DOM UI pages use extension APIs). >> Where do I start? Is this a bad idea? >> >> Another option is to keep the bookmarks manager as a special extension >> that is always turned on. >> >> [*] Extensions do not have enough privileges and there aren't enough >> hooks to allow extensions to do all the things the bookmark manager >> needs to do. I've filed bugs for everything I've run into. >> >> erik >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
Seems like a bad idea. Extensions and DOMUI are basically two competing systems for doing the same thing, it would get confusing combining them. I would rather either: a) add new (possibly experimental) APIs for the issues you've run into. b) manually plumb the extension APIs you need through DOMUI (this is basically composition instead of inheritance) Is this the complete list of bugs? http://code.google.com/p/chromium/issues/list?can=2&q=feature:extensions+reporter:arv Context menu is potentially on the M5 list. Depending on how complex a context menu API you want, this might not be too bad. We should just implement the chrome:// urls one I guess. - a On Mon, Dec 14, 2009 at 3:36 PM, Erik Arvidsson wrote: > I'm in the process of writing a bookmark manager in HTML. So far I've > written it as an extension but I'm now considering changing this to a > DOM UI page instead. [*] > > I would like to be able to expose the extensions API for bookmarks to > the DOM UI (and eventually make all DOM UI pages use extension APIs). > Where do I start? Is this a bad idea? > > Another option is to keep the bookmarks manager as a special extension > that is always turned on. > > [*] Extensions do not have enough privileges and there aren't enough > hooks to allow extensions to do all the things the bookmark manager > needs to do. I've filed bugs for everything I've run into. > > erik > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
