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
== Likely Future Modules ==
filesystem = DISCUSS BEFORE MODULARIZATION
notifications = DISCUSS BEFORE MODULARIZATION
pagevisibility = DISCUSS BEFORE MODULARIZATION
protocolhandler = DISCUSS BEFORE MODULARIZATION
websql = DISCUSS BEFORE MODULARIZATION
webaudio = DISCUSS BEFORE
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
==
On Wed, Feb 29, 2012 at 11:31 PM, Maciej Stachowiak m...@apple.com wrote:
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
Thank you very much for the organization. Your suggestion sounds great to me.
Just for clarification, I would like to confirm what action we should
take for each item from now:
== Existing Modules ==
gamepad = KEEP
geolocation = KEEP
indexeddb (work in progress) = KEEP
intents = KEEP
On Wed, Feb 29, 2012 at 11:49 PM, Kentaro Hara hara...@chromium.org wrote:
Thank you very much for the organization. Your suggestion sounds great to me.
Just for clarification, I would like to confirm what action we should
take for each item from now:
== Existing Modules ==
gamepad = KEEP
Nice. Is there a plan for modularizing Settings?
On Feb 28, 2012 12:30 AM, Adam Barth aba...@webkit.org 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
We haven't done anything about Settings yet, but Setting is also kind
of growing out of control. My initial read is that we should try to
autogenerate Settings (and maybe some/all of the Settings-related
boilerplate in the WebKit layer) from an in file.
Adam
On Tue, Feb 28, 2012 at 7:40 AM,
Good idea!
-Darin
On Tue, Feb 28, 2012 at 8:46 AM, Adam Barth aba...@webkit.org wrote:
We haven't done anything about Settings yet, but Setting is also kind
of growing out of control. My initial read is that we should try to
autogenerate Settings (and maybe some/all of the Settings-related
Yeah. I haven't studied the Settings issue carefully yet. If you
look at patches that add a new setting, they need to add a ridiculous
amount of boilerplate code, especially if they want to test the
setting. Reducing this overhead seems valuable (whether by
autogeneration or other means),
The main issue isn't that the settings are large and unwieldy. I thought
the point of the modularization effort was to enable partitioning of
features. That means eliminating files that enumerate each feature. That
said, we might still have classes that need to mention all features, so to
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
On Tue, Feb 28, 2012 at 11:11 AM, Alexey Proskuryakov a...@webkit.org wrote:
Having read the wiki page, I'm even more unhappy with the approach that
has been taken than I used to be. In fact, it is harmful even to the goals
of the refactoring.
If a single #ifdefed line in DOMWindow.idl is a
28.02.2012, в 11:25, Darin Fisher написал(а):
Is this something the build system could help address? Perhaps a by-product
of the build is or could be a single file that contains everything that will
be exposed on WorkerContext / DOMWindow?
Some of these concerns could be alleviated with
On Tue, Feb 28, 2012 at 11:24 AM, Maciej Stachowiak m...@apple.com wrote:
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
On Tue, Feb 28, 2012 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote:
But it seems like what is actually happening is wholesale rapid application
of this pattern to all of WebCore, including even things that aren't in the
Modules directory. So it's starting to seem more like a major
2012/2/28 Alexey Proskuryakov a...@webkit.org:
- separation of concerns seems incorrect (not all code with WebSocket in
the name is WebSocket code is the concern of engineers who solely focus on
WebSocket).
Do you have a concrete example of this sort of code? It's easier to
talk concretely
On Tue, Feb 28, 2012 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote:
From the initial mail about modules, I got the (perhaps mistaken) impression
that it would be used only for selected features that had very loose
coupling and were perhaps not even of interest to every port. That seemed
On Tue, Feb 28, 2012 at 1:59 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 28, 2012, at 12:20 PM, Adam Barth wrote:
On Tue, Feb 28, 2012 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote:
But it seems like what is actually happening is wholesale rapid application
of this pattern to all
On Tue, Feb 28, 2012 at 4:43 PM, Kentaro Hara hara...@chromium.org wrote:
First of all, I am sorry we have done things too aggressively without
a community consensus. I'll stop committing patches until reaching a
consensus, and am happy to revert some patches that have already
committed.
As
So my answer to Maciej's second question:
2) To what extent should Module-like techniques be applied to non-Modules?
is that let us stop applying Module-like techniques to non-Modules,
until the modularization techniques mature well and the advantages of
applying it become obvious. If there
21 matches
Mail list logo
