Re: [webkit-dev] WebKit modularization
2012/2/27 Alexey Proskuryakov :
> 27.02.2012, в 11:54, Adam Barth написал(а):
>> Huh? I'm sorry, I thought I addressed all the issues you spotted.
>> Are there more I missed? I certainly don't have any wish (or
>> motivation) to mess up the copyright blocks.
>
> Thank you!
>
> I made the conclusion that you were unwilling to address the remaining issues
> based on the fact that a number of them remain unaddressed, and that your
> response was just that you'll be more careful in the future.
>
>> Two have been fixed and one was in a patch that was never reviewed or landed.
>
> Which bug has the patch? I can't find it in request queue.
This is the one that was in a patch that was never reviewed or landed:
https://bugs.webkit.org/attachment.cgi?id=128716&action=review
We're still working on removing ENABLE(SQL_DATABASE) ifdefs from
WebCore proper (e.g., I need to address Morrita's comments on
https://bugs.webkit.org/show_bug.cgi?id=79633). We'll likely come
back to this patch once we've made more progress on SQL database, and
hopefully we'll get the copyright block right then.
> I have now spent the time to hunt down a few more specific license issues
> currently in ToT:
>
> JSDOMWebAudioCustom.cpp is LGPL
> JSDOMWindowWebSocketCustom.cpp is LGPL
> DOMWindowSQLDatabase.cpp and .h have Google as copyright holder (I'm fairly
> sure this code was written by Apple)
> NavigatorGeolocation.{h,cpp,idl} have Google as copyright holder, which may
> or may not be correct (I think it's Apple)
> NavigatorMediaStream.{h,cpp,idl} have Google as copyright holder, which may
> or may not be correct (I think it's Ericsson)
> DOMURLMediaStream.idl is LGPL
Thanks. I'll fix these by EOD.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
27.02.2012, в 11:54, Adam Barth написал(а):
> Huh? I'm sorry, I thought I addressed all the issues you spotted.
> Are there more I missed? I certainly don't have any wish (or
> motivation) to mess up the copyright blocks.
Thank you!
I made the conclusion that you were unwilling to address the remaining issues
based on the fact that a number of them remain unaddressed, and that your
response was just that you'll be more careful in the future.
> Two have been fixed and one was in a patch that was never reviewed or landed.
Which bug has the patch? I can't find it in request queue.
I have now spent the time to hunt down a few more specific license issues
currently in ToT:
JSDOMWebAudioCustom.cpp is LGPL
JSDOMWindowWebSocketCustom.cpp is LGPL
DOMWindowSQLDatabase.cpp and .h have Google as copyright holder (I'm fairly
sure this code was written by Apple)
NavigatorGeolocation.{h,cpp,idl} have Google as copyright holder, which may or
may not be correct (I think it's Apple)
NavigatorMediaStream.{h,cpp,idl} have Google as copyright holder, which may or
may not be correct (I think it's Ericsson)
DOMURLMediaStream.idl is LGPL
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
2012/2/27 Adam Barth : > 2012/2/27 Alexey Proskuryakov : >> >> 24.02.2012, в 10:00, Adam Barth написал(а): >> >>> I'm happy to re-check them for license errors. If you can send me a >>> list of the license errors you've noticed, I'll make sure they get >>> addressed. >> >> For the record, I sent comments via private e-mail, and Adam refused to >> follow up on this promise (there was a partial patch he made before >> receiving my e-mail, but that was all). A number the files still have >> license errors, mostly copyright assigned to Google on code that was written >> by others. I did not send a specific list of things to fix, however I don't >> think that it's too much to ask one to go through patches in a specific area >> they reviewed recently. >> >> I'm deeply concerned about the way this refactoring is implemented - it >> doesn't have much of a meaningful purpose overall, and patches are reviewed >> carelessly. > > Huh? I'm sorry, I thought I addressed all the issues you spotted. > Are there more I missed? I certainly don't have any wish (or > motivation) to mess up the copyright blocks. For the record, I re-checked the three issues Alexey pointed me to in private email. Two have been fixed and one was in a patch that was never reviewed or landed. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
2012/2/27 Alexey Proskuryakov : > > 24.02.2012, в 10:00, Adam Barth написал(а): > >> I'm happy to re-check them for license errors. If you can send me a >> list of the license errors you've noticed, I'll make sure they get >> addressed. > > For the record, I sent comments via private e-mail, and Adam refused to > follow up on this promise (there was a partial patch he made before receiving > my e-mail, but that was all). A number the files still have license errors, > mostly copyright assigned to Google on code that was written by others. I did > not send a specific list of things to fix, however I don't think that it's > too much to ask one to go through patches in a specific area they reviewed > recently. > > I'm deeply concerned about the way this refactoring is implemented - it > doesn't have much of a meaningful purpose overall, and patches are reviewed > carelessly. Huh? I'm sorry, I thought I addressed all the issues you spotted. Are there more I missed? I certainly don't have any wish (or motivation) to mess up the copyright blocks. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
24.02.2012, в 10:00, Adam Barth написал(а): > I'm happy to re-check them for license errors. If you can send me a > list of the license errors you've noticed, I'll make sure they get > addressed. For the record, I sent comments via private e-mail, and Adam refused to follow up on this promise (there was a partial patch he made before receiving my e-mail, but that was all). A number the files still have license errors, mostly copyright assigned to Google on code that was written by others. I did not send a specific list of things to fix, however I don't think that it's too much to ask one to go through patches in a specific area they reviewed recently. I'm deeply concerned about the way this refactoring is implemented - it doesn't have much of a meaningful purpose overall, and patches are reviewed carelessly. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
On Feb 24, 2012, at 9:57 AM, Alexey Proskuryakov wrote: > > 22.02.2012, в 22:08, Kentaro Hara написал(а): > >> TL;DR: We are starting WebKit modularization. Self-contained features >> like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved >> from WebCore/ to WebCore/Modules/. > > Looking at patches that are actually getting landed, they go far beyond this > idea. See e.g. bug 79436 - "Move HTML-related APIs from DOMWindow.idl to > DOMWindowHTML.idl". How is HTML a self-contained feature? > > I see a lot of downside in such refactoring, and don't really see any benefit: > > 1) It gets very hard to navigate source code, as you never know where a given > function is. You can't find it, you can't see if it's even there without a > full code search. > 2) The division lines are very arbitrary. For example, bug 79434 moved > "XML-related" APIs to a separate file, including window.XMLDocument, which is > as core to DOM as it gets. > 3) The moves don't respect original licenses - e.g. DOMWindowXML.idl is LGPL, > while DOMWindow.idl is BSD. > 4) More files means longer build times. > > I think that most of the patches landed under this umbrella should be > reconsidered, and most immediately those that had license wrong. I too am surprised that HTML-related APIs would be refactored as a result of modularization. This change may be justifiable on its own merits, but it doesn't seem like a logical part of a project to make self-contained features more modular. At the very least, to avoid confusion, changes like that should be kept clearly separate from the modularization effort, or else, someone could explain the relationship if there is one and its not obvious. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
2012/2/24 Alexey Proskuryakov : > 22.02.2012, в 22:08, Kentaro Hara написал(а): > >> TL;DR: We are starting WebKit modularization. Self-contained features >> like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved >> from WebCore/ to WebCore/Modules/. > > Looking at patches that are actually getting landed, they go far beyond this > idea. See e.g. bug 79436 - "Move HTML-related APIs from DOMWindow.idl to > DOMWindowHTML.idl". How is HTML a self-contained feature? > > I see a lot of downside in such refactoring, and don't really see any benefit: > > 1) It gets very hard to navigate source code, as you never know where a given > function is. You can't find it, you can't see if it's even there without a > full code search. > 2) The division lines are very arbitrary. For example, bug 79434 moved > "XML-related" APIs to a separate file, including window.XMLDocument, which is > as core to DOM as it gets. > 3) The moves don't respect original licenses - e.g. DOMWindowXML.idl is LGPL, > while DOMWindow.idl is BSD. > 4) More files means longer build times. > > I think that most of the patches landed under this umbrella should be > reconsidered, and most immediately those that had license wrong. I'm happy to re-check them for license errors. If you can send me a list of the license errors you've noticed, I'll make sure they get addressed. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
22.02.2012, в 22:08, Kentaro Hara написал(а): > TL;DR: We are starting WebKit modularization. Self-contained features > like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved > from WebCore/ to WebCore/Modules/. Looking at patches that are actually getting landed, they go far beyond this idea. See e.g. bug 79436 - "Move HTML-related APIs from DOMWindow.idl to DOMWindowHTML.idl". How is HTML a self-contained feature? I see a lot of downside in such refactoring, and don't really see any benefit: 1) It gets very hard to navigate source code, as you never know where a given function is. You can't find it, you can't see if it's even there without a full code search. 2) The division lines are very arbitrary. For example, bug 79434 moved "XML-related" APIs to a separate file, including window.XMLDocument, which is as core to DOM as it gets. 3) The moves don't respect original licenses - e.g. DOMWindowXML.idl is LGPL, while DOMWindow.idl is BSD. 4) More files means longer build times. I think that most of the patches landed under this umbrella should be reconsidered, and most immediately those that had license wrong. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
On Thu, Feb 23, 2012 at 10:36 AM, Simon Fraser wrote: > On Feb 23, 2012, at 10:24 AM, Adam Barth wrote: >> On Thu, Feb 23, 2012 at 10:07 AM, Simon Fraser >> wrote: >>> On Feb 22, 2012, at 10:08 PM, Kentaro Hara wrote: TL;DR: We are starting WebKit modularization. Self-contained features like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved from WebCore/ to WebCore/Modules/. >>> >>> What are the interfaces that a module uses to call into WebCore code, and >>> vice versa? >> >> Currently, the plan is that there won't be any direct dependencies >> from WebCore into code in Modules, but code in Modules will be able to >> depend on anything in WebCore it likes. We've added a couple abstract >> "Observer" interfaces that Modules use to learn about what's happening >> in WebCore. So far, these have been very basic lifetime-related >> observations (e.g., a Page and/or a Frame being >> destroyed/disconnected): >> >> http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameDestructionObserver.h >> >> The goal is to avoid adding much to these interfaces so that folks can >> work on WebCore proper without worrying too much about these >> "ancillary" features. >> >> This diagram describes the dependency relationships: >> >> https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?authkey=CP6plYAI > > From this, it looks like the only way for a module to get instantiated at > runtime > is via bindings. Is that correct? Yes, that's correct. In some cases, "controller" objects (which today are created by Page itself) are instead instantiated by the WebKit layer when associating clients with the Page. However, these objects don't do much unless they're tickled via the bindings. > Is module availability simply determined > at build time via ENBALE flags? To the build system, files in the Modules directory look just like files in any other directory. Nothing is changing in this regard. (I think that means the answer to your question is "yes".) >>> Will these be developed in an ad hoc manner, or is the intent >>> to create some kind of generic extensibility API that modules use to >>> hook into WebCore? >> >> Ad-hoc. At least in the near-to-intermediate term, all this code is >> going to continue to live in Source/WebCore, so we're not creating any >> new API commitments. In the long term, we might benefit from moving >> some of it out of WebCore entirely, but that's not something we're >> planning to tackle any time soon. > > I see. I just want to avoid the need for lots of intra-WebCore interfaces, as > I'm sure you do too. Yes, definitely. On Thu, Feb 23, 2012 at 10:54 AM, Pavel Feldman wrote: > On Thu, Feb 23, 2012 at 10:24 PM, Adam Barth wrote: >> On Thu, Feb 23, 2012 at 10:07 AM, Simon Fraser >> wrote: >> > On Feb 22, 2012, at 10:08 PM, Kentaro Hara wrote: >> >> TL;DR: We are starting WebKit modularization. Self-contained features >> >> like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved >> >> from WebCore/ to WebCore/Modules/. >> > >> > What are the interfaces that a module uses to call into WebCore code, >> > and >> > vice versa? >> >> Currently, the plan is that there won't be any direct dependencies >> from WebCore into code in Modules, but code in Modules will be able to >> depend on anything in WebCore it likes. We've added a couple abstract >> "Observer" interfaces that Modules use to learn about what's happening >> in WebCore. So far, these have been very basic lifetime-related >> observations (e.g., a Page and/or a Frame being >> destroyed/disconnected): > > It means that we'll need to put inspector agents (FileSystem, IndexedDB, > AppCache, etc.) into corresponding modules. As of today, they are > instantiated by the InspectorController. We will also need to split > InspectorInstrumentation into parts. This is all doable, but is an effort. > Were you planning to do it on your own? Please keep inspector folks in the > loop. I haven't looked much at the inspector agents. I wasn't planning to worry about this in the near term. If you think it would benefit the inspector to change how this works today, we can certainly coordinate. If the current approach is working fine for you, I'd be inclined to wait. On Thu, Feb 23, 2012 at 11:16 AM, Martin Robinson wrote: > Is it too ugly to reach across layers and use these interfaces in > WebKit? They might come in handy. I've already looked at one patch > that uses FrameDestructionObserver in WebKit. I don't have a strong opinion on this topic. FrameDestructionObserver is remarkably useful. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
On Thu, Feb 23, 2012 at 10:24 AM, Adam Barth wrote: > Currently, the plan is that there won't be any direct dependencies > from WebCore into code in Modules, but code in Modules will be able to > depend on anything in WebCore it likes. We've added a couple abstract > "Observer" interfaces that Modules use to learn about what's happening > in WebCore. So far, these have been very basic lifetime-related > observations (e.g., a Page and/or a Frame being > destroyed/disconnected): > > http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameDestructionObserver.h Is it too ugly to reach across layers and use these interfaces in WebKit? They might come in handy. I've already looked at one patch that uses FrameDestructionObserver in WebKit. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
On Thu, Feb 23, 2012 at 10:24 PM, Adam Barth wrote: > On Thu, Feb 23, 2012 at 10:07 AM, Simon Fraser > wrote: > > On Feb 22, 2012, at 10:08 PM, Kentaro Hara wrote: > >> TL;DR: We are starting WebKit modularization. Self-contained features > >> like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved > >> from WebCore/ to WebCore/Modules/. > > > > What are the interfaces that a module uses to call into WebCore code, and > > vice versa? > > Currently, the plan is that there won't be any direct dependencies > from WebCore into code in Modules, but code in Modules will be able to > depend on anything in WebCore it likes. We've added a couple abstract > "Observer" interfaces that Modules use to learn about what's happening > in WebCore. So far, these have been very basic lifetime-related > observations (e.g., a Page and/or a Frame being > destroyed/disconnected): > > It means that we'll need to put inspector agents (FileSystem, IndexedDB, AppCache, etc.) into corresponding modules. As of today, they are instantiated by the InspectorController. We will also need to split InspectorInstrumentation into parts. This is all doable, but is an effort. Were you planning to do it on your own? Please keep inspector folks in the loop. > > http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameDestructionObserver.h > > The goal is to avoid adding much to these interfaces so that folks can > work on WebCore proper without worrying too much about these > "ancillary" features. > > This diagram describes the dependency relationships: > > > https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?authkey=CP6plYAI > > > Will these be developed in an ad hoc manner, or is the intent > > to create some kind of generic extensibility API that modules use to > > hook into WebCore? > > Ad-hoc. At least in the near-to-intermediate term, all this code is > going to continue to live in Source/WebCore, so we're not creating any > new API commitments. In the long term, we might benefit from moving > some of it out of WebCore entirely, but that's not something we're > planning to tackle any time soon. > > Adam > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
On Feb 23, 2012, at 10:24 AM, Adam Barth wrote: > On Thu, Feb 23, 2012 at 10:07 AM, Simon Fraser wrote: >> On Feb 22, 2012, at 10:08 PM, Kentaro Hara wrote: >>> TL;DR: We are starting WebKit modularization. Self-contained features >>> like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved >>> from WebCore/ to WebCore/Modules/. >> >> What are the interfaces that a module uses to call into WebCore code, and >> vice versa? > > Currently, the plan is that there won't be any direct dependencies > from WebCore into code in Modules, but code in Modules will be able to > depend on anything in WebCore it likes. We've added a couple abstract > "Observer" interfaces that Modules use to learn about what's happening > in WebCore. So far, these have been very basic lifetime-related > observations (e.g., a Page and/or a Frame being > destroyed/disconnected): > > http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameDestructionObserver.h > > The goal is to avoid adding much to these interfaces so that folks can > work on WebCore proper without worrying too much about these > "ancillary" features. > > This diagram describes the dependency relationships: > > https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?authkey=CP6plYAI >From this, it looks like the only way for a module to get instantiated at >runtime is via bindings. Is that correct? Is module availability simply determined at build time via ENBALE flags? > >> Will these be developed in an ad hoc manner, or is the intent >> to create some kind of generic extensibility API that modules use to >> hook into WebCore? > > Ad-hoc. At least in the near-to-intermediate term, all this code is > going to continue to live in Source/WebCore, so we're not creating any > new API commitments. In the long term, we might benefit from moving > some of it out of WebCore entirely, but that's not something we're > planning to tackle any time soon. I see. I just want to avoid the need for lots of intra-WebCore interfaces, as I'm sure you do too. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
On Thu, Feb 23, 2012 at 10:07 AM, Simon Fraser wrote: > On Feb 22, 2012, at 10:08 PM, Kentaro Hara wrote: >> TL;DR: We are starting WebKit modularization. Self-contained features >> like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved >> from WebCore/ to WebCore/Modules/. > > What are the interfaces that a module uses to call into WebCore code, and > vice versa? Currently, the plan is that there won't be any direct dependencies from WebCore into code in Modules, but code in Modules will be able to depend on anything in WebCore it likes. We've added a couple abstract "Observer" interfaces that Modules use to learn about what's happening in WebCore. So far, these have been very basic lifetime-related observations (e.g., a Page and/or a Frame being destroyed/disconnected): http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameDestructionObserver.h The goal is to avoid adding much to these interfaces so that folks can work on WebCore proper without worrying too much about these "ancillary" features. This diagram describes the dependency relationships: https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?authkey=CP6plYAI > Will these be developed in an ad hoc manner, or is the intent > to create some kind of generic extensibility API that modules use to > hook into WebCore? Ad-hoc. At least in the near-to-intermediate term, all this code is going to continue to live in Source/WebCore, so we're not creating any new API commitments. In the long term, we might benefit from moving some of it out of WebCore entirely, but that's not something we're planning to tackle any time soon. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
On Feb 22, 2012, at 10:08 PM, Kentaro Hara wrote: > TL;DR: We are starting WebKit modularization. Self-contained features > like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved > from WebCore/ to WebCore/Modules/. What are the interfaces that a module uses to call into WebCore code, and vice versa? Will these be developed in an ad hoc manner, or is the intent to create some kind of generic extensibility API that modules use to hook into WebCore? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
Adam, Sounds good. Consider me working on WorkerContext. I'll create a separate bug for moving file-api out of WorkerContext and create a patch for moving it to the temp. destination per the spreadsheet. Regarding the build system, I couldn't agree more. I'd like to help in improving it. I have some tasks on the back-burner, but it's a bigger bite than I can muster the time for, at least for now. But I agree moving platform sounds like the one with the bigger impact. I'm in Yerevan, Armenia UTC+4, btw. -Ash From: Adam Barth To: Ashod Nakashian Cc: Kentaro Hara ; WebKit Development Sent: Thursday, February 23, 2012 12:29 PM Subject: Re: [webkit-dev] WebKit modularization On Thu, Feb 23, 2012 at 12:18 AM, Ashod Nakashian wrote: >> TL;DR: We are starting WebKit modularization. Self-contained features > like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved > from WebCore/ to WebCore/Modules/. > > Are there plans to split the project build files as well into separate > sub-projects? That's not something we're planning to do in the short term, but it's a logical next step. If the project had a sane build system, we'd probably do that sooner rather than later. :) The bigger project in that regard is moving WebCore/platform into a separate project called Platform. That would significantly reduce the number of files and lines of code in WebCore. IMHO, that's more valuable in the near term. > Probably that's a separate undertaking, as it's not trivial. However I think > it would be very beneficial to make each module independent with its own > build scripts that produce library files. WebCore build could link all the > modules into one final library, as is the case now, so nothing outside of > WebCore changes as far as building the "upstream" projects are concerned. > This approach would also minimize the feature-enabling infrastructure, as > enabling modularized features would mean either they are built (and linked) > or skipped. This would make the builds potentially faster and more > manageable, allowing for module building and testing independently of > WebCore and in faster iterations. Splitting the project build files should > probably have its separate bug report with dependency on this one. > > As an aside, I'd like to volunteer to work on the modularization bug. How > can I coordinate my efforts and with whom? Depending on your time zone, feel free to ping Kentaro or me on #webkit. An easy thing to do is to pick a block of lines from the spreadsheet Kentaro linked to below, write a patch, and upload it to a bug blocking <https://bugs.webkit.org/show_bug.cgi?id=79327>. For example, you could write an analogous patch to <https://bugs.webkit.org/attachment.cgi?id=128247&action=review> for moving the ENABLE(FILE_SYSTEM) code out of WorkerContext. That's lines 485-492 on the spreadsheet. Thanks! Adam > ____ > From: Kentaro Hara > To: WebKit Development > Sent: Thursday, February 23, 2012 10:08 AM > Subject: [webkit-dev] WebKit modularization > > TL;DR: We are starting WebKit modularization. Self-contained features > like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved > from WebCore/ to WebCore/Modules/. > > > We are planning to modularize WebKit. We are planning to split > "self-contained" features out of WebCore/ into WebCore/Modules/. For > example, we can move WebAudio, WebSocket, IndexedDB, ...etc from > WebCore/ to WebCore/Modules/ as self-contained features. > > The idea is that modules roughly correspond to features/specifications > that aren't core to the rendering engine (like a CSS feature might > be). Usually a module will be introduced with a corresponding ENABLE > flag. Modules do not depend on each other. The dependency rule ensures > that nothing outside the module will be burdened with knowledge or > complexity of the ENABLE flag. > > Modules enable us to develop self-contained features without touching > WebCore/ code. We hope this will make it much easier to develop > vendor-specific features. > > The meta bug is here: https://bugs.webkit.org/show_bug.cgi?id=79327 > > The WebKit modularization is realized by the [Supplemental] IDL > attribute. You can find more information of [Supplemental] here: > https://trac.webkit.org/wiki/WebKitIDL#Supplemental > > The WebKit modularization plan is here: > https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AppchfQ5mBrEdFlodHlLb0prdEd1ZEZyUHdCbEpoc2c#gid=0 > > In the above SpreadSheet, there are two columns, "Temporary > destination" and "Final destination". The "Final destination" > indicates the direc
Re: [webkit-dev] WebKit modularization
On Thu, Feb 23, 2012 at 12:18 AM, Ashod Nakashian wrote: >> TL;DR: We are starting WebKit modularization. Self-contained features > like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved > from WebCore/ to WebCore/Modules/. > > Are there plans to split the project build files as well into separate > sub-projects? That's not something we're planning to do in the short term, but it's a logical next step. If the project had a sane build system, we'd probably do that sooner rather than later. :) The bigger project in that regard is moving WebCore/platform into a separate project called Platform. That would significantly reduce the number of files and lines of code in WebCore. IMHO, that's more valuable in the near term. > Probably that's a separate undertaking, as it's not trivial. However I think > it would be very beneficial to make each module independent with its own > build scripts that produce library files. WebCore build could link all the > modules into one final library, as is the case now, so nothing outside of > WebCore changes as far as building the "upstream" projects are concerned. > This approach would also minimize the feature-enabling infrastructure, as > enabling modularized features would mean either they are built (and linked) > or skipped. This would make the builds potentially faster and more > manageable, allowing for module building and testing independently of > WebCore and in faster iterations. Splitting the project build files should > probably have its separate bug report with dependency on this one. > > As an aside, I'd like to volunteer to work on the modularization bug. How > can I coordinate my efforts and with whom? Depending on your time zone, feel free to ping Kentaro or me on #webkit. An easy thing to do is to pick a block of lines from the spreadsheet Kentaro linked to below, write a patch, and upload it to a bug blocking <https://bugs.webkit.org/show_bug.cgi?id=79327>. For example, you could write an analogous patch to <https://bugs.webkit.org/attachment.cgi?id=128247&action=review> for moving the ENABLE(FILE_SYSTEM) code out of WorkerContext. That's lines 485-492 on the spreadsheet. Thanks! Adam > ____________ > From: Kentaro Hara > To: WebKit Development > Sent: Thursday, February 23, 2012 10:08 AM > Subject: [webkit-dev] WebKit modularization > > TL;DR: We are starting WebKit modularization. Self-contained features > like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved > from WebCore/ to WebCore/Modules/. > > > We are planning to modularize WebKit. We are planning to split > "self-contained" features out of WebCore/ into WebCore/Modules/. For > example, we can move WebAudio, WebSocket, IndexedDB, ...etc from > WebCore/ to WebCore/Modules/ as self-contained features. > > The idea is that modules roughly correspond to features/specifications > that aren't core to the rendering engine (like a CSS feature might > be). Usually a module will be introduced with a corresponding ENABLE > flag. Modules do not depend on each other. The dependency rule ensures > that nothing outside the module will be burdened with knowledge or > complexity of the ENABLE flag. > > Modules enable us to develop self-contained features without touching > WebCore/ code. We hope this will make it much easier to develop > vendor-specific features. > > The meta bug is here: https://bugs.webkit.org/show_bug.cgi?id=79327 > > The WebKit modularization is realized by the [Supplemental] IDL > attribute. You can find more information of [Supplemental] here: > https://trac.webkit.org/wiki/WebKitIDL#Supplemental > > The WebKit modularization plan is here: > https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AppchfQ5mBrEdFlodHlLb0prdEd1ZEZyUHdCbEpoc2c#gid=0 > > In the above SpreadSheet, there are two columns, "Temporary > destination" and "Final destination". The "Final destination" > indicates the directory to which we want to move the APIs eventually. > That being said, sometimes the API move requires non-trivial changes > or discussions with API maintainers. For example, moving all File APIs > to WebCore/Modules/filesystem/ at a breath would be too complex and > controversial. For such APIs, we are planning to first move the APIs > to the "Temporary destination", (which would be trivial and harmless,) > and then move the APIs to the "Final destination" based on the > discussion with API maintainers. > > If you have any concern, please let me know. Thanks! > > > -- > Kentaro Hara, Tokyo, Japan (http://haraken.info) > ___ > webki
Re: [webkit-dev] WebKit modularization
Hi, > TL;DR: We are starting WebKit modularization. Self-contained featureslike >WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved from WebCore/ to WebCore/Modules/. Are there plans to split the project build files as well into separate sub-projects? Probably that's a separate undertaking, as it's not trivial. However I think it would be very beneficial to make each module independent with its own build scripts that produce library files. WebCore build could link all the modules into one final library, as is the case now, so nothing outside of WebCore changes as far as building the "upstream" projects are concerned. This approach would also minimize the feature-enabling infrastructure, as enabling modularized features would mean either they are built (and linked) or skipped. This would make the builds potentially faster and more manageable, allowing for module building and testing independently of WebCore and in faster iterations. Splitting the project build files should probably have its separate bug report with dependency on this one. As an aside, I'd like to volunteer to work on the modularization bug. How can I coordinate my efforts and with whom? -Ash From: Kentaro Hara To: WebKit Development Sent: Thursday, February 23, 2012 10:08 AM Subject: [webkit-dev] WebKit modularization TL;DR: We are starting WebKit modularization. Self-contained features like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved from WebCore/ to WebCore/Modules/. We are planning to modularize WebKit. We are planning to split "self-contained" features out of WebCore/ into WebCore/Modules/. For example, we can move WebAudio, WebSocket, IndexedDB, ...etc from WebCore/ to WebCore/Modules/ as self-contained features. The idea is that modules roughly correspond to features/specifications that aren't core to the rendering engine (like a CSS feature might be). Usually a module will be introduced with a corresponding ENABLE flag. Modules do not depend on each other. The dependency rule ensures that nothing outside the module will be burdened with knowledge or complexity of the ENABLE flag. Modules enable us to develop self-contained features without touching WebCore/ code. We hope this will make it much easier to develop vendor-specific features. The meta bug is here: https://bugs.webkit.org/show_bug.cgi?id=79327 The WebKit modularization is realized by the [Supplemental] IDL attribute. You can find more information of [Supplemental] here: https://trac.webkit.org/wiki/WebKitIDL#Supplemental The WebKit modularization plan is here: https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AppchfQ5mBrEdFlodHlLb0prdEd1ZEZyUHdCbEpoc2c#gid=0 In the above SpreadSheet, there are two columns, "Temporary destination" and "Final destination". The "Final destination" indicates the directory to which we want to move the APIs eventually. That being said, sometimes the API move requires non-trivial changes or discussions with API maintainers. For example, moving all File APIs to WebCore/Modules/filesystem/ at a breath would be too complex and controversial. For such APIs, we are planning to first move the APIs to the "Temporary destination", (which would be trivial and harmless,) and then move the APIs to the "Final destination" based on the discussion with API maintainers. If you have any concern, please let me know. Thanks! -- Kentaro Hara, Tokyo, Japan (http://haraken.info) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
Here are a couple example of a patches that are part of this project: https://bugs.webkit.org/attachment.cgi?id=128395&action=review https://bugs.webkit.org/attachment.cgi?id=128247&action=review Notice that we've removed a bunch of feature-spec code from "core" classes like DOMWindow and Page. The code we're removing doesn't really have anything to do with the primary work done by DOMWindow or Page. The code just uses DOMWindow or Page as a context object. The net result (hopefully!) is that the core classes should have less code and many fewer ifdefs. Adam On Wed, Feb 22, 2012 at 10:08 PM, Kentaro Hara wrote: > TL;DR: We are starting WebKit modularization. Self-contained features > like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved > from WebCore/ to WebCore/Modules/. > > > We are planning to modularize WebKit. We are planning to split > "self-contained" features out of WebCore/ into WebCore/Modules/. For > example, we can move WebAudio, WebSocket, IndexedDB, ...etc from > WebCore/ to WebCore/Modules/ as self-contained features. > > The idea is that modules roughly correspond to features/specifications > that aren't core to the rendering engine (like a CSS feature might > be). Usually a module will be introduced with a corresponding ENABLE > flag. Modules do not depend on each other. The dependency rule ensures > that nothing outside the module will be burdened with knowledge or > complexity of the ENABLE flag. > > Modules enable us to develop self-contained features without touching > WebCore/ code. We hope this will make it much easier to develop > vendor-specific features. > > The meta bug is here: https://bugs.webkit.org/show_bug.cgi?id=79327 > > The WebKit modularization is realized by the [Supplemental] IDL > attribute. You can find more information of [Supplemental] here: > https://trac.webkit.org/wiki/WebKitIDL#Supplemental > > The WebKit modularization plan is here: > https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AppchfQ5mBrEdFlodHlLb0prdEd1ZEZyUHdCbEpoc2c#gid=0 > > In the above SpreadSheet, there are two columns, "Temporary > destination" and "Final destination". The "Final destination" > indicates the directory to which we want to move the APIs eventually. > That being said, sometimes the API move requires non-trivial changes > or discussions with API maintainers. For example, moving all File APIs > to WebCore/Modules/filesystem/ at a breath would be too complex and > controversial. For such APIs, we are planning to first move the APIs > to the "Temporary destination", (which would be trivial and harmless,) > and then move the APIs to the "Final destination" based on the > discussion with API maintainers. > > If you have any concern, please let me know. Thanks! > > > -- > Kentaro Hara, Tokyo, Japan (http://haraken.info) > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit modularization
TL;DR: We are starting WebKit modularization. Self-contained features like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved from WebCore/ to WebCore/Modules/. We are planning to modularize WebKit. We are planning to split "self-contained" features out of WebCore/ into WebCore/Modules/. For example, we can move WebAudio, WebSocket, IndexedDB, ...etc from WebCore/ to WebCore/Modules/ as self-contained features. The idea is that modules roughly correspond to features/specifications that aren't core to the rendering engine (like a CSS feature might be). Usually a module will be introduced with a corresponding ENABLE flag. Modules do not depend on each other. The dependency rule ensures that nothing outside the module will be burdened with knowledge or complexity of the ENABLE flag. Modules enable us to develop self-contained features without touching WebCore/ code. We hope this will make it much easier to develop vendor-specific features. The meta bug is here: https://bugs.webkit.org/show_bug.cgi?id=79327 The WebKit modularization is realized by the [Supplemental] IDL attribute. You can find more information of [Supplemental] here: https://trac.webkit.org/wiki/WebKitIDL#Supplemental The WebKit modularization plan is here: https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AppchfQ5mBrEdFlodHlLb0prdEd1ZEZyUHdCbEpoc2c#gid=0 In the above SpreadSheet, there are two columns, "Temporary destination" and "Final destination". The "Final destination" indicates the directory to which we want to move the APIs eventually. That being said, sometimes the API move requires non-trivial changes or discussions with API maintainers. For example, moving all File APIs to WebCore/Modules/filesystem/ at a breath would be too complex and controversial. For such APIs, we are planning to first move the APIs to the "Temporary destination", (which would be trivial and harmless,) and then move the APIs to the "Final destination" based on the discussion with API maintainers. If you have any concern, please let me know. Thanks! -- Kentaro Hara, Tokyo, Japan (http://haraken.info) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
