[chromium-dev] Re: Should all automatable browser APIs have per-object unique IDs?
On Thu, Mar 26, 2009 at 9:41 AM, Aaron Boodman 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Should all automatable browser APIs have per-object unique IDs?
On Thu, Mar 26, 2009 at 9:52 AM, Brett Wilson wrote: > What would IDs refer to in history? I've only barely looked into the history data model, but I was hoping it would be a persistent ID for each visit, which is unique across the profile. It appears that there is such an ID in the visit table. Could I use that? - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Should all automatable browser APIs have per-object unique IDs?
On Thu, Mar 26, 2009 at 10:09 AM, Aaron Boodman wrote: > > On Thu, Mar 26, 2009 at 9:52 AM, Brett Wilson wrote: >> What would IDs refer to in history? > > I've only barely looked into the history data model, but I was hoping > it would be a persistent ID for each visit, which is unique across the > profile. It appears that there is such an ID in the visit table. Could > I use that? Those are exposed, but I wonder which cases an extension needs to refer to them. They are internal IDs generated by sqlite. If you clear your history, you'll get re-used ones. This could also theoretically possible happen if you delete a single item, but I don't know if this happens in practice. So they are often persistent, but the way you ask makes me nervous. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Should all automatable browser APIs have per-object unique IDs?
On Thu, Mar 26, 2009 at 11:22 AM, Brett Wilson wrote: > Those are exposed, but I wonder which cases an extension needs to > refer to them. They are internal IDs generated by sqlite. If you clear > your history, you'll get re-used ones. This could also theoretically > possible happen if you delete a single item, but I don't know if this > happens in practice. So they are often persistent, but the way you ask > makes me nervous. I'm thinking of a use case where somebody wanted to synchronize browser history between machines. It would be more convenient to do this if there was a unique client side ID that didn't change for each visit. I admit this is probably a far-out use case, but I figured if it was easy to enable, we might as well. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Should all automatable browser APIs have per-object unique IDs?
On Thu, Mar 26, 2009 at 11:37 AM, Aaron Boodman wrote: > On Thu, Mar 26, 2009 at 11:22 AM, Brett Wilson wrote: >> Those are exposed, but I wonder which cases an extension needs to >> refer to them. They are internal IDs generated by sqlite. If you clear >> your history, you'll get re-used ones. This could also theoretically >> possible happen if you delete a single item, but I don't know if this >> happens in practice. So they are often persistent, but the way you ask >> makes me nervous. > > I'm thinking of a use case where somebody wanted to synchronize > browser history between machines. It would be more convenient to do > this if there was a unique client side ID that didn't change for each > visit. I'm OK exposing this as long as we set expectations correctly. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
