On Wed, Apr 22, 2009 at 5:14 PM, Nick Baum <[email protected]> wrote:
> Thanks for doing this. Comments inline.
>
> 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.
>
> Agree. So would we split "browser" into "tabs" and "windows" modules?
Actually it is already split. We never made the change to the code to
"browser". I've changed the docs to reflect the current reality.
>> 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.
>
> I liked the idea of passing the full new state, and a list of previous
> values for properties that had changed.
> However, if that's hard to implement, what you described seems fine.
Passing the old state will definitely be hard (it basically means we
need to keep copies of the current state so that we have it when it
changes ... or we need to change the various models to pass the old
state of the values that change).
>> 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?
>>
> Hmm, onBookmarkOrderChanged seems cleaner to me. What's the disadvantage of
> going with that?
My feeling is that our current API design is very low level. It is a
JavaScripty version of a message-passing API. We already assume in
some places that you are keeping state. For example, when you remove a
Tab, we don't send you back the new state -- we assume you know that
the hole will be filled. When you get an onTabUpdated event, I'm
proposing only sending the changed properties, not the entire object
again.
It is consistent with this then, that move *not* send the entire new
set of ids in order because we again assume that you understand that
moving a tab from A to B will affect other tabs.
I agree this kind of stinks, but I feel like it's a slippery slope
sending more information. Why send all the ids and not the object data
too? Why not send children? Etc, etc, etc. Just sending the changed
info is nice and clean, to me anyway.
- a
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
