On Mon, Apr 27, 2009 at 10:26 AM, Aaron Boodman <[email protected]> wrote:
> On Mon, Apr 27, 2009 at 10:00 AM, Erik Kay <[email protected]> wrote: > > On Wed, Apr 22, 2009 at 3:35 PM, Aaron Boodman <[email protected]> wrote: > >> 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 like how this approach feels, and I think we should do it. That said, > I > > have a few concerns that I think we need to keep an eye on. > > What if there are some properties that are heavier weight and potentially > > have more specific notification and error conditions with you try to > change > > them. The side effect of grouping changes to multiple fields with > different > > update semantics is that you'll get a weird mishmash. > > For example, let's say you're updating three properties in tab, and two > of > > them could actually fail according to the underlying browser API for some > > reason. This means that updates might have partially succeeded (I doubt > we > > want to try to implement transactions), and you might have multiple > > independent error messages. > > Right. My instinct was that we would have to pre-validate all the > changes. I don't think this is too hard for the cases I can imagine, > since we're essentially single threaded by the time we get to the > place we need to make the changes. But maybe there are some > difficulties I'm not considering. I don't think we should hold up the change for this, but I don't think we can externally validate. If the underlying setter can fail, then it seems unlikely that we can validate in exactly the same way as it can. Aside from duplicating code, some failures could be externalities (filesystem issues for example). Again, let's move forward. If we run into anything like this, I think the fix will be simply to move that field out of the legal fields for the general update method. >> Question: Do we need to send fromIndex? > > > > 'need' is a strong word. Does it hurt to do so? I could imagine that > it's > > useful for maintaining state to minimize the amount of re-shuffling you > need > > to do. Incidentally, doesn't this notification also need a fromWindow? > > Yeah, I'm just trying to figure out where to draw the line on how much > preexisting state to send. I don't have a strong opinion. As for > fromWindow, no. The underlying support distinguishes between moving > between windows and moving within a tab, and we decided that we had to > expose this. OK. In the bookmark case, the fromParent will need to be in the notification. Unfortunately, I guess this shows how we can't generalize / standardize the APIs too much across different systems. Erik --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
