I'm starting to dig into implementing the tab and window API as a first example of all the other browser-automation type APIs we eventually want to implement for extensions.
One of my early assumptions was that the APIs we exposed would be service-style, where we pass dumb json data structures back and forth between the extension process and the browser process. As such, it seems intuitive that each object must have a unique identifier. For example, each tab should have a tab ID and each window should have a window ID. (For more detail, see here: http://dev.chromium.org/developers/design-documents/extensions/api-pattern) The automation system already maintains such a list of IDs for tabs, browsers, and windows for a similar reason. But they are maintained in the automation class hierarchy and not particularly useful to me. I was wondering what people thought of the idea of changing these objects to have built-in IDs for automation purposes. So, for example, each Browser would have an ID, and there'd be a map of ID to instance maintained in BrowserList. Clients (the automation system and the extension system) then wouldn't have to maintain their own mappings, but could call BrowserList::GetBrowserById(), or something. Same with Tabs, Downloads, Bookmarks*, and History*. * Bookmarks already appear to have an ID, but it only lasts the session. I have a hunch it will work better if persistent data like bookmarks and history have persistent IDs, but I haven't thought this through yet. - a --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
