+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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
