That's fine. As I said before, As it appears that nobody else does either, I'll make this a TODO to sweep through and fix.
- a On Wed, Apr 29, 2009 at 1:51 PM, Ben Goodger (Google) <[email protected]> wrote: > I'll raise this again: > > your js object that methods hang off should be called "chrome" not > "chromium"... we use "chrome" in all of our other API points > (chrome-ui:// and chrome-extensions:// protocol schemes, the user > agent string etc). > > FYI - Chromium is the name of the project, not the product, and should > never appear in code. I should probably add this to the style guide on > dev.chromium.org! > > -Ben > > On Wed, Apr 22, 2009 at 3:35 PM, Aaron Boodman <[email protected]> wrote: >> >> A few of us extension guys were talking offline Monday about how now >> that we've all had a chance to implement some APIs, we are probably >> better positioned to come to consensus on the remaining style points. >> >> I went through the existing three browser APIs (windows, tabs, and >> bookmarks -- http://dev.chromium.org/developers/design-documents/extensions) >> and tried to identify all the places where they differ. I've also put >> my vote for whether and how they should be aligned. >> >> Let me know what you think... >> >> Naming: >> - We have chromium.windows.getWindows(), >> chromium.windows.createWindow(), etc and chromium.bookmarks.get(), >> chromium.bookmarks.create(). >> - My vote: I like chromium.bookmarks.create(). The downside to this is >> that we can never put more than one primary object in a namespace, but >> I'm OK with that. We should also change the event names to be like >> onMove instead of onTabMoved. >> >> Querying: >> - We have getWindows(WindowQuery), getTabs(TabQuery), and >> bookmarks.get(ids)+bookmarks.search(text). >> - My vote: It doesn't look to me like there is a general solution >> here. Searching for windows and tabs using multiple criterion >> (WindowQuery, TabQuery) feels pretty hard to use to me. Doing so in >> history feels more natural. Doing so for bookmarks is kinda in >> between. I feel like for these we might want to do things that are >> more optimized for the module in question. For example >> windows.getTop(), windows.getCurrent(), bookmarks.getTree(), etc. I'll >> start separate conversations for these, though. >> >> Updating: >> - We have bookmarks.setTitle(id, title) and windows.updateWindow({id, >> top, left, width, height, ...}) >> - My vote. I like the single update method for objects that naturally >> have lots of fields you can update. For bookmarks, for example, you >> will eventually be able to update both url and title. It seems natural >> to me to be able to do both at the same time. It also lends itself >> well to batch operations, should we ever want to do that. I also >> really like Rafael's idea to separate out the id parameter, so it >> would look like windows.updateWindow(id, {top, left, width, height, >> ...}). This elegantly solves the problem of accidentally using an old >> object and clobbering more recent state. If we do this, probably we >> should also split out id in the move apis, to be consistent. >> >> Update Event: >> - Sometimes we pass old and new objects according to the docs, but I >> think it will be difficult to actually do that. >> - My vote: onUpdate(int id, {properties and values that changed}). The >> second param would be an object containing the names of the properties >> that changed and their new values. >> >> Move Event: >> - We have onBookmarkOrderChanged(int folderid, int[] newchildids) and >> onTabMoved(int tabid, int windowid, int fromindex, int toindex) >> - My vote: I think we should go with onTabMoved(int tabid, int >> newindex). In other places we have assumed that the client is keeping >> state, so this should be the same. We'd still send only one move event >> and assume the client either understands the implied shuffling, or >> will refetch the entire list. Question: Do we need to send fromIndex? >> >> >> - a >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
