Thanks! I updated the docs at http://dev.chromium.org/developers/coding-style
-Ben On Wed, Apr 29, 2009 at 1:54 PM, Aaron Boodman <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
