(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 <tha...@google.com> 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 <erik...@chromium.org> wrote: >> On Mon, Dec 14, 2009 at 6:24 PM, Aaron Boodman <a...@chromium.org> wrote: >>> >>> On Mon, Dec 14, 2009 at 5:43 PM, Erik Kay <erik...@chromium.org> wrote: >>> > On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman <a...@chromium.org> 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
