On Thu, Mar 26, 2009 at 9:41 AM, Aaron Boodman <a...@chromium.org> wrote:
> 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*.
What would IDs refer to in history?
Brett
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
