On Wed, Apr 8, 2009 at 7:11 PM, Aaron Boodman <[email protected]> wrote:
> > Argh, resending from right adress this time. > > On Wed, Apr 8, 2009 at 7:10 PM, Aaron Boodman <[email protected]> wrote: > > Thanks for forking this. I had started a reply, then forgot to send it. > > > > On Wed, Apr 8, 2009 at 4:57 PM, Nick Baum <[email protected]> wrote: > >> [forking the "Basic how-to steps" thread] > >> I was rereading this, and it seems this wasn't completely resolved. I've > >> summarized the various topics: > >> Syntax > >> It feels like Erik has a somewhat different syntax in mind (still > service > >> based, but a little more OO). I think the most useful thing at this > point > >> would be for Erik to give an example of what he proposes so we can > compare > >> the two. > > > > Yes, agree counterproposals would be easier to digest. > > > > From what I understand of the save() proposal, it doesn't seem to > > provide much value. You get to say foo.save() instead of > > chromium.foos.updateFoo(foo). I guess it's less typing, but if all the > > other functions to get, delete, and create foo objects are on > > chromium.foos, I don't see why it's valuable to have the update > > function not be there. There are other advantages to > > chorium.foos.updateFoo(). It can easily be modified to accept multiple > > foo instances. This could be useful if we need to make sure that a > > bunch of updates happen without repaints between. > > > > > >> Updates > >> I like Erik's suggestion of keeping change bits, it's clever and > transparent > >> to the developer. For update events, do we only send the ID and the > fields > >> that have changed? I can see it being useful to have the whole object, > but > >> that makes figuring out the changes tricky. Maybe we send all fields in > the > >> new object, but only the changed fields in the old object. That makes it > >> easy to find out which ones have changed, while still giving you the > whole > >> object. > > > > The change bit idea is interesting. I'm not sure exactly what Erik had > > in mind for how it would work, but I can imagine a few ways: > > > > a) Use javascript prototypes. When you call getThing(), you get back > > an empty object whose __proto__ is the actual object with its fields > > filled in. But when you mutate your thing instance, your writes get > > saved on the empty object. That way if you try to save it again, we > > can tell the difference. > > > > b) __defineSetter__. We'd intercept writes to fields and save a > > modified bit somewhere. > > > > I think a) is better. If we find that this is a common problem, we > > could try it out. I'd rather get more APIs built out in the > > dead-simple JSON style though before going deeper on the API > > infrastructure. > > > > > >> Camel-case > >> I've seen arguments both ways. I like camelcase better because it's more > >> legible, but don't feel strongly about. > > > > I'm convinced we should change it back to camel case. And I also agree > > we should avoid DOM event names if possible. > > > >> Tabs & windows > >> Another difference between tabs and windows is that tabs have prev/next > >> history that we should let developers navigate. To me they seem separate > >> enough to be worth separating to not get three dozen functions in one > >> package, but I don't feel strongly about this. I might sketch out what > >> they'd look like if separate. > > > > Sure, let's try them separated for awhile. > Ok, I'll take a stab at spec'ing this up. -Nick > > > > >> Self vs extension > >> Is this just a naming issue? Have we decided? > > > > I'll rename the property in content scripts called 'self' to > 'parentExtension'. > > > > - a > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
