>> == 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 MODULARIZATION > > ^^^ I'd like to modularize these two relatively soon. webaudio is > basically done. We're just waiting for crogers to give us the thumbs > up to move the files. As for websql, it seems very parallel to > indexeddb and likely should be implemented using a similar approach.
Yeah. I just wanted to mean that "let's announce here before starting modularization". Now I understand the modularization can be controversial. Another thing I've heard is that some folk got confused because we've moved websockets/ directory without the announcement. On Thu, Mar 1, 2012 at 4:56 PM, Adam Barth <[email protected]> wrote: > On Wed, Feb 29, 2012 at 11:49 PM, Kentaro Hara <[email protected]> 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 >> geolocation => KEEP >> indexeddb (work in progress) => KEEP >> intents => KEEP >> mediastream => KEEP >> vibration => KEEP >> websockets => KEEP >> >> >> == 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 MODULARIZATION > > ^^^ I'd like to modularize these two relatively soon. webaudio is > basically done. We're just waiting for crogers to give us the thumbs > up to move the files. As for websql, it seems very parallel to > indexeddb and likely should be implemented using a similar approach. > > Adam > > >> == Non-Modules Using Module-Related Techniques for Loose Coupling == >> >> devicemotion => KEEP >> deviceoritentation => KEEP >> html (seems to be agreement on reverting this) => REVERT >> speechinput (seems to be agreement on keeping this) => KEEP >> svg => REVERT >> webgl => REVERT >> workers => REVERT >> xml => REVERT >> >> == Possibly Planned Future Uses of Module Techniques for non-Modules == >> >> events => WONT MODULARIZE >> >> >> If you have any concern, let's discuss here. If no objection, I'll >> start the above work from tomorrow. >> >> >> >> On Thu, Mar 1, 2012 at 4:31 PM, Maciej Stachowiak <[email protected]> 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 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 >>> >> >> >> >> -- >> Kentaro Hara, Tokyo, Japan (http://haraken.info) -- Kentaro Hara, Tokyo, Japan (http://haraken.info) _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
