One thing that would be helpful to add is an explanation of what types of subsystems should be turned into Modules and what types should not. Also advantages and disadvantages of turning a particular piece of code into a Module.
I think part of the confusion/controversy around these changes may relate to which pieces of code are treated as a Module and why, rather than what the mechanics are for turning something into a Module. Regards, Maciej On Feb 28, 2012, at 12:29 AM, Adam Barth wrote: > I wrote up a short wiki page explaining how the modules system works > and how to use it when building new features: > > https://trac.webkit.org/wiki/Modules > > We've been making good progress refactoring some existing features to > use the system. This refactoring both improves the hackability of > WebCore by simplifying the core objects (e.g., > Page/DOMWindow/Document/Navigator) and paves the cowpaths for new code > to avoid bloating these objects. > > In Bug 79663, Alexey asked why we were moving the WebSocket > declaration out of WorkerContext.idl and into Modules/websockets. > Viewed in isolation, I can understand why that change looks somewhat > mysterious. Hopefully the wiki page above provides some more context > for the change. In particular, WebSockets fits neatly into the > modules pattern. We've already removed almost all mentions of > WebSockets from WebCore proper. Besides one item in > WebCore::Settings, WorkerContext.idl is the last file in WebCore > proper to mention WebSockets. > > Adam > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
