I think how to split/refactor depends on the feature, understanding the current code, and working with the appropriate webkit dev. For workers, we thought about how/where it made sense to split the impl for chrome and talked with a...@webkit about it. There was some iteration as we figured out things better and as he made suggestions and it has worked out fine so far.
On Wed, Apr 29, 2009 at 11:49 AM, Michael Nordman <[email protected]>wrote: > > +chromium-dev > > Designing things in this front/back fashion and re-using the code > entirely in chrome removes at least one high-coefficient of friction > surface rubbing between the chromium and webkit teams. We will likely > pay a higher price up front, but it should pay dividends down the > road. Add an interesting feature and iphone, andriod, chrome, and > safari all pick it up. > > I'm worried about the logistics of pulling this off for the appcache > given the existing impl is live and in use in iphone and safari and > soon andriod. We're talking about 'refactoring' or 'replacing' > existing impls with new ones that support a remote backend. How can we > reduce the upfront cost? > > * maybe build these new impls out in webcore w/o disrupting the existing > impl > * use the new impl for chrome (and any other webkit consumer that > wishes to compile the new impls in would be free to do so) > * somewhere down the road, deprecate the existing impl in favor of the > new impl in webcore > > We haven't talked to the webkit guys about logistics like this, no > data on where their head is? > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
