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 -~----------~----~----~----~------~----~------~--~---
