It seems that we have some agreement on what to modularize, but not necessarily agreement on what the modularization should encompass.
For example, I think that <https://bugs.webkit.org/show_bug.cgi?id=80193> that moves some knowledge of what makes a page uncacheable out of PageCache::canCachePageContainingThisFrame makes the code less hackable, and is likely to become a disadvantage. - WBR, Alexey Proskuryakov 29.02.2012, в 23:31, Maciej Stachowiak написал(а): > > Here's an update of my lists based on the notes from you, Adam and others: > > == Existing Modules == > > gamepad > geolocation > indexeddb (work in progress) > intents > mediastream > vibration > websockets > > > == Likely Future Modules == > > filesystem > notifications > pagevisibility > protocolhandler > websql > webaudio > > > == Non-Modules Using Module-Related Techniques for Loose Coupling == > > devicemotion > deviceoritentation > html (seems to be agreement on reverting this) > speechinput (seems to be agreement on keeping this) > svg > webgl > workers > xml > > == Possibly Planned Future Uses of Module Techniques for non-Modules == > > events > > > ---------- > > Assuming this reflects up-to-date plans, I can put it in a wiki page, though > I'm not sure I'll always be able to keep it up to date with changes of plans. > > I would suggest that, based on the discussion so far, html, svg, webgl, > workers, and xml should be de-quasi-modularized at least for now. I would > also suggest not applying Module techniques to DOM events, at least for now, > unless I misunderstand the intent. devicemotion and deviceorientation seem to > be using Supplement<> in a similar way and for a similar reason to > speechinput, so I'd presume folks are ok with those. > > We may also want to consider whether websockets is truly a good candidate for > the module treatment. It seems to me that at some point soon, if not already, > it will be mature and accepted enough to be considered part of the core, > though the code is relatively standalone. > > Regards, > Maciej > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
