Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

Don and I have implemented this at 
https://bugs.webkit.org/show_bug.cgi?id=143358

I think we're all ready to go! Reviews welcome!

(mcatanzaro: feel free to do a partial review for the non-Xcode build stuff )

--Myles

> On Jan 18, 2017, at 1:39 PM, Alex Christensen  wrote:
> 
> Windows must also stay a static library.  I can volunteer the 
> currently-completely-experimental-anyways Mac CMake build to have PAL as a 
> shared library.  It would be nice if people had more of a reason to keep it 
> working.
>> On Jan 18, 2017, at 1:23 PM, Michael Catanzaro  wrote:
>> 
>> On Wed, 2017-01-18 at 12:17 -0800, Myles C. Maxfield wrote:
>>> Static (At least for the Xcode projects. I imagine the cmake-based
>>> projects could do whatever they want here).
>> 
>> For GTK+ we really want static as well, we do not want a new shared
>> library. So no difference here.
>> 
>> Michael
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Alex Christensen]

Windows must also stay a static library.  I can volunteer the 
currently-completely-experimental-anyways Mac CMake build to have PAL as a 
shared library.  It would be nice if people had more of a reason to keep it 
working.
> On Jan 18, 2017, at 1:23 PM, Michael Catanzaro  wrote:
> 
> On Wed, 2017-01-18 at 12:17 -0800, Myles C. Maxfield wrote:
>> Static (At least for the Xcode projects. I imagine the cmake-based
>> projects could do whatever they want here).
> 
> For GTK+ we really want static as well, we do not want a new shared
> library. So no difference here.
> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Michael Catanzaro]

On Wed, 2017-01-18 at 12:17 -0800, Myles C. Maxfield wrote:
> Static (At least for the Xcode projects. I imagine the cmake-based
> projects could do whatever they want here).

For GTK+ we really want static as well, we do not want a new shared
library. So no difference here.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

Alright - I’ve had a long and involved conversation with people who know things 
about Apple’s internal build infrastructure. The result of this conversation is:

1. Currently, the build infrastructure is configured in such a way as to not be 
compatible with a new folder in the top-level Source directory. Therefore, PAL 
must live inside a subdirectory of WebCore for now. We have plans to 
reconfigure the build infrastructure to relax this constraint, but it is 
difficult enough that it won’t be done soon. Once the constraint is relaxed, we 
can move PAL to a top-level directory inside Source.

2. Making a new Xcode project for PAL is the most sensible way forward.

I think this unblocks us. I’ll answer all the open questions inline below.

—Myles

> On Jan 14, 2017, at 12:39 PM, Myles C. Maxfield  wrote:
> 
> Here’s a quick rundown of where we stand. Please correct me if any of this is 
> inaccurate.
> 
> There are a few separate issues:
> Path on disk of PAL folder: Sounds like everyone more-or-less agrees that 
> this should belong in Source/, not in Source/WebCore/. However, I believe 
> this is currently incompatible with Apple’s internal build infrastructure. If 
> that’s true, then this issue is decided.

Source/WebCore/PAL

> Namespace of PAL symbols: Sounds like everyone agrees there should just be a 
> top-level namespace PAL (and not WebCore::PAL).

PAL, not WebCore::PAL

> #include style of PAL headers: Sounds like everyone agrees this should be the 
>  style. There are two ways to achieve this:
> Add WebCore/ to the search path, and put PAL files in WebCore/pal/. This has 
> a problem where it is easy to include other files inside WebCore but outside 
> of PAL, since they are in the search path. This is the approach Don and I 
> took in our patch, and solved this problem by using the Python script to 
> check the #include lines.
> Put PAL files in WebCore/PAL/pal/, and add WebCore/PAL/ to the search path. 
> This has the same problem WTF has where there is a nested folder with the 
> same name.

The second option

> Presence of an Xcode project: Sounds like this is possible and the best way 
> forward. Does this work back to the earliest OS we build on?

Yes

> Static library or shared library: I was under the impression that using a 
> shared library could potentially have performance problems, which would not 
> occur with a static library. However, a shared library would enforce layering 
> naturally, whereas a static library would need either
> An application to link to it and not to WebCore, such as a unit test suite, or
> Some out-of-band layering enforcement, like a Python script.
>   I’m a little hesitant to rely on a testing application to 
> enforce layering in shipping code because some ports may choose not to build 
> those tests.

Static (At least for the Xcode projects. I imagine the cmake-based projects 
could do whatever they want here).

> 
> 
> 
> 
> So, here are the items which need to be solved:
> Do Xcode cross-project references work going back to the oldest Xcode we 
> build on?
> Regarding issue #2 above, should I put source files in WebCore/pal or 
> WebCore/PAL/pal?
> How do people feel about relying on a non-shipping application to enforce 
> laying in shipping code?
> 
> 
> Also (note to self): I need to figure out the ForwardingHeaders story.
> 
> —Myles
> 
>> On Jan 14, 2017, at 10:47 AM, Konstantin Tokarev > > wrote:
>> 
>> 
>> 
>> 14.01.2017, 17:16, "Fujii Hironori" > >:
>>> On Sat, Jan 14, 2017 at 1:34 AM, Konstantin Tokarev >> > wrote:
  Static library is just an (indexed) archive of object files, symbol 
 dependencies are not resolved when it is created. Instead this happens 
 when static library is linked into shared library or executable.
 
  If PAL is static and uses symbol from WebCore, link failure may happen 
 only[*] if that symbol is not used anywhere in WebCore itself (provided 
 that PAL stays after WebCore in linker command line and options like 
 --start-group/--end-group are not used).
 
  [*] Assuming linker behavior similar to ELF linkers
>>> 
>>> You can check unresolved symbols of the static library by creating a
>>> unit test executable of PAL.
>> 
>> Actually, it enough just to avoid adding WebCore to include directories of 
>> PAL, and code with layering violation won't compile.
>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> -- 
>> Regards,
>> Konstantin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> 

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

The ar utility isn’t a linker - it just collects object files. I don’t believe 
it has any concept of matching symbols up to exported symbols in external 
shared libraries (like JavaScriptCore for WTF).

(But of course someone can correct me if I’m wrong.)

—Myles

> On Jan 14, 2017, at 1:38 PM, Darin Adler  wrote:
> 
>> On Jan 14, 2017, at 12:39 PM, Myles C. Maxfield  wrote:
>> 
>> However, a shared library would enforce layering naturally, whereas a static 
>> library would need either an application to link to it and not to WebCore, 
>> such as a unit test suite, or some out-of-band layering enforcement, like a 
>> Python script.
> 
> I’m surprised to learn this. There is no way to build a static library that 
> gives us linker errors if there are unresolved references?
> 
> — Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Darin Adler]

> On Jan 14, 2017, at 12:39 PM, Myles C. Maxfield  wrote:
> 
> However, a shared library would enforce layering naturally, whereas a static 
> library would need either an application to link to it and not to WebCore, 
> such as a unit test suite, or some out-of-band layering enforcement, like a 
> Python script.

I’m surprised to learn this. There is no way to build a static library that 
gives us linker errors if there are unresolved references?

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Maciej Stachowiak]

> On Jan 14, 2017, at 12:39 PM, Myles C. Maxfield  wrote:
> 
> Here’s a quick rundown of where we stand. Please correct me if any of this is 
> inaccurate.
> 
> There are a few separate issues:
> Path on disk of PAL folder: Sounds like everyone more-or-less agrees that 
> this should belong in Source/, not in Source/WebCore/. However, I believe 
> this is currently incompatible with Apple’s internal build infrastructure. If 
> that’s true, then this issue is decided.

While there are extra steps required, we can resolve this for PAL the same as 
was done for WTF. Or at least, I don't know of any issues that apply to PAL 
which did not apply to WTF at the time we moved it out. If you think you know 
of a reason and it's stuff we shouldn't talk about here, I'd be glad to discuss 
off-list.

> Namespace of PAL symbols: Sounds like everyone agrees there should just be a 
> top-level namespace PAL (and not WebCore::PAL).
> #include style of PAL headers: Sounds like everyone agrees this should be the 
>  style. There are two ways to achieve this:
> Add WebCore/ to the search path, and put PAL files in WebCore/pal/. This has 
> a problem where it is easy to include other files inside WebCore but outside 
> of PAL, since they are in the search path. This is the approach Don and I 
> took in our patch, and solved this problem by using the Python script to 
> check the #include lines.
> Put PAL files in WebCore/PAL/pal/, and add WebCore/PAL/ to the search path. 
> This has the same problem WTF has where there is a nested folder with the 
> same name.

Don't we have these same two choices if the include style is ? 
However, this concern is moot if PAL becomes a top-level item under Source, or 
at least is planned to go there even if not immediately.

> Presence of an Xcode project: Sounds like this is possible and the best way 
> forward. Does this work back to the earliest OS we build on?
> Static library or shared library: I was under the impression that using a 
> shared library could potentially have performance problems, which would not 
> occur with a static library. However, a shared library would enforce layering 
> naturally, whereas a static library would need either
> An application to link to it and not to WebCore, such as a unit test suite, or
> Some out-of-band layering enforcement, like a Python script.
>   I’m a little hesitant to rely on a testing application to 
> enforce layering in shipping code because some ports may choose not to build 
> those tests.

WTF works fine as a static library that's layered under JavaScriptCore, and it 
doesn't have any kind of out-of-band enforcement tool. As far as I know, this 
works fine and has never led to a layering violation or other problem. The only 
enforcement is that WTF builds as a separate static library in a separate 
project, and doesn't include JavaScriptCore headers.

Once again I would suggest that "do what WTF does" is likely to be a good 
solution.

> 
> 
> 
> 
> So, here are the items which need to be solved:
> Do Xcode cross-project references work going back to the oldest Xcode we 
> build on?
> Regarding issue #2 above, should I put source files in WebCore/pal or 
> WebCore/PAL/pal?

I prefer the latter because: (a) it's more forward-looking if we eventually 
move PAL out to its own top level; and (b) it won't accidentally allow includes 
of other WebCore headers through an overly-broad include path.

> How do people feel about relying on a non-shipping application to enforce 
> laying in shipping code?

It seems unnecessary. Being a separate module under source (or setting 
everything up as if it were that way already until we can move it) is 
sufficient for this kind of thing, as demonstrated by WTF.

> 
> 
> Also (note to self): I need to figure out the ForwardingHeaders story.
> 
> —Myles
> 
>> On Jan 14, 2017, at 10:47 AM, Konstantin Tokarev > > wrote:
>> 
>> 
>> 
>> 14.01.2017, 17:16, "Fujii Hironori" > >:
>>> On Sat, Jan 14, 2017 at 1:34 AM, Konstantin Tokarev >> > wrote:
  Static library is just an (indexed) archive of object files, symbol 
 dependencies are not resolved when it is created. Instead this happens 
 when static library is linked into shared library or executable.
 
  If PAL is static and uses symbol from WebCore, link failure may happen 
 only[*] if that symbol is not used anywhere in WebCore itself (provided 
 that PAL stays after WebCore in linker command line and options like 
 --start-group/--end-group are not used).
 
  [*] Assuming linker behavior similar to ELF linkers
>>> 
>>> You can check unresolved symbols of the static library by creating a
>>> unit test executable of PAL.
>> 
>> Actually, it enough just to avoid adding WebCore to include directories of 
>> PAL, and code with 

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

Here’s a quick rundown of where we stand. Please correct me if any of this is 
inaccurate.

There are a few separate issues:
Path on disk of PAL folder: Sounds like everyone more-or-less agrees that this 
should belong in Source/, not in Source/WebCore/. However, I believe this is 
currently incompatible with Apple’s internal build infrastructure. If that’s 
true, then this issue is decided.
Namespace of PAL symbols: Sounds like everyone agrees there should just be a 
top-level namespace PAL (and not WebCore::PAL).
#include style of PAL headers: Sounds like everyone agrees this should be the 
 style. There are two ways to achieve this:
Add WebCore/ to the search path, and put PAL files in WebCore/pal/. This has a 
problem where it is easy to include other files inside WebCore but outside of 
PAL, since they are in the search path. This is the approach Don and I took in 
our patch, and solved this problem by using the Python script to check the 
#include lines.
Put PAL files in WebCore/PAL/pal/, and add WebCore/PAL/ to the search path. 
This has the same problem WTF has where there is a nested folder with the same 
name.
Presence of an Xcode project: Sounds like this is possible and the best way 
forward. Does this work back to the earliest OS we build on?
Static library or shared library: I was under the impression that using a 
shared library could potentially have performance problems, which would not 
occur with a static library. However, a shared library would enforce layering 
naturally, whereas a static library would need either
An application to link to it and not to WebCore, such as a unit test suite, or
Some out-of-band layering enforcement, like a Python script.
I’m a little hesitant to rely on a testing application to 
enforce layering in shipping code because some ports may choose not to build 
those tests.




So, here are the items which need to be solved:
Do Xcode cross-project references work going back to the oldest Xcode we build 
on?
Regarding issue #2 above, should I put source files in WebCore/pal or 
WebCore/PAL/pal?
How do people feel about relying on a non-shipping application to enforce 
laying in shipping code?


Also (note to self): I need to figure out the ForwardingHeaders story.

—Myles

> On Jan 14, 2017, at 10:47 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 14.01.2017, 17:16, "Fujii Hironori" :
>> On Sat, Jan 14, 2017 at 1:34 AM, Konstantin Tokarev  
>> wrote:
>>>  Static library is just an (indexed) archive of object files, symbol 
>>> dependencies are not resolved when it is created. Instead this happens when 
>>> static library is linked into shared library or executable.
>>> 
>>>  If PAL is static and uses symbol from WebCore, link failure may happen 
>>> only[*] if that symbol is not used anywhere in WebCore itself (provided 
>>> that PAL stays after WebCore in linker command line and options like 
>>> --start-group/--end-group are not used).
>>> 
>>>  [*] Assuming linker behavior similar to ELF linkers
>> 
>> You can check unresolved symbols of the static library by creating a
>> unit test executable of PAL.
> 
> Actually, it enough just to avoid adding WebCore to include directories of 
> PAL, and code with layering violation won't compile.
> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Konstantin Tokarev]

13.01.2017, 19:26, "Michael Catanzaro" :
> On Fri, 2017-01-13 at 11:39 -0200, Gustavo Sverzut Barbieri wrote:
>>  On Thu, Jan 12, 2017 at 7:11 PM, Alex Christensen
>>   wrote:
>>  > If PAL were a shared library in a CMake build, then it wouldn’t
>>  > build successfully if there were layering violations.  I think we
>>  > should do something like that to enforce good design, even if the
>>  > Mac Xcode projects treat it as a static library or even just a part
>>  > of WebCore.
>
> Why does it matter if it's static or shared? Surely if PAL is build
> before WebCore, and it's missing symbols at link time (because those
> symbols actually exist in WebCore) and not linked to WebCore, then PAL
> will fail to link regardless of whether it is a shared library or
> static library? Am I just downright wrong to assume this, or does it
> work differently on Mac...?

Static library is just an (indexed) archive of object files, symbol 
dependencies are not resolved when it is created. Instead this happens when 
static library is linked into shared library or executable.

If PAL is static and uses symbol from WebCore, link failure may happen only[*] 
if that symbol is not used anywhere in WebCore itself (provided that PAL stays 
after WebCore in linker command line and options like --start-group/--end-group 
are not used).

[*] Assuming linker behavior similar to ELF linkers

>
> (This is the biggest problem I see with the current plan. Regardless of
> where the directory goes and what the namespacing looks like, I really
> want to use the linker and not a python script to enforce layering.)
>
>>  Actually for development it would make lives much easier to keep it
>>  as shared library, reducing compile time and help to segment the
>>  symbols in a different space (linkers, gdb)
>>
>>  what if it becomes shared by default on Debug builds, static by
>>  default in Release?
>
> For GTK+, I'd really like it to be always a static lib as that's what
> we need to ship and I wouldn't want to support multiple configurations.
> Debug fission has solved our troubles with link time and gdb slowness.
> But here it's possible for different ports to do different things. E.g.
> some ports support building WebCore as a shared library, which is not
> supported by GTK+.
>
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Michael Catanzaro]

On Fri, 2017-01-13 at 11:39 -0200, Gustavo Sverzut Barbieri wrote:
> On Thu, Jan 12, 2017 at 7:11 PM, Alex Christensen
>  wrote:
> > If PAL were a shared library in a CMake build, then it wouldn’t
> > build successfully if there were layering violations.  I think we
> > should do something like that to enforce good design, even if the
> > Mac Xcode projects treat it as a static library or even just a part
> > of WebCore.

Why does it matter if it's static or shared? Surely if PAL is build
before WebCore, and it's missing symbols at link time (because those
symbols actually exist in WebCore) and not linked to WebCore, then PAL
will fail to link regardless of whether it is a shared library or 
static library? Am I just downright wrong to assume this, or does it
work differently on Mac...?

(This is the biggest problem I see with the current plan. Regardless of
where the directory goes and what the namespacing looks like, I really
want to use the linker and not a python script to enforce layering.)

> Actually for development it would make lives much easier to keep it
> as shared library, reducing compile time and help to segment the
> symbols in a different space (linkers, gdb)
> 
> what if it becomes shared by default on Debug builds, static by
> default in Release? 

For GTK+, I'd really like it to be always a static lib as that's what
we need to ship and I wouldn't want to support multiple configurations.
Debug fission has solved our troubles with link time and gdb slowness.
But here it's possible for different ports to do different things. E.g.
some ports support building WebCore as a shared library, which is not
supported by GTK+.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Gustavo Sverzut Barbieri]

On Thu, Jan 12, 2017 at 7:11 PM, Alex Christensen 
wrote:

> If PAL were a shared library in a CMake build, then it wouldn’t build
> successfully if there were layering violations.  I think we should do
> something like that to enforce good design, even if the Mac Xcode projects
> treat it as a static library or even just a part of WebCore.


Actually for development it would make lives much easier to keep it as
shared library, reducing compile time and help to segment the symbols in a
different space (linkers, gdb)

what if it becomes shared by default on Debug builds, static by default in
Release?

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN, GTalk, FaceTime: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (16) 99354-9890
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Alex Christensen]

If PAL were a shared library in a CMake build, then it wouldn’t build 
successfully if there were layering violations.  I think we should do something 
like that to enforce good design, even if the Mac Xcode projects treat it as a 
static library or even just a part of WebCore.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Dan Bernstein]

> On Jan 11, 2017, at 5:43 PM, Maciej Stachowiak <m...@apple.com> wrote:
> 
> 
> To be clear, I think PAL is a great move. Details like the namespace, 
> placement of the code, and how includes look are all things that can be 
> changed after the fact.
> 
> That said, I think we need to ultimately consider our porting layer to be the 
> combination of PAL and WTF, so it is good for the two to be consistent. I 
> hope revisions along these lines can be considered in due course.

Indeed, some considerations relating to the Apple production build process led 
me to suggest that we avoid adding another subdirectory under Source. I believe 
that at some point in the future, those considerations will no longer hold. 
Even before then, while still keeping the PAL source code inside 
Source/WebCore, we should be able to take advantage of Xcode’s support for 
cross-project references and create a separate Xcode project for PAL (in a 
subdirectory of Source/WebCore), which will allow for better—or at least 
simpler—enforcement of the separation (and for an easier move to a top-level 
Source subdirectory in the future).

> 
> Regards,
> Maciej
> 
>> On Jan 11, 2017, at 3:30 PM, Olmstead, Don <don.olmst...@sony.com 
>> <mailto:don.olmst...@sony.com>> wrote:
>> 
>> I was the one who did the WebCore::PAL namespace so I wanted to chime in on 
>> why I went that route. We at Sony are newcomers to pushing to trunk so my 
>> explanation might be entirely too idealistic but here goes.
>>  
>> I had thought of PAL as a library that is internal to WebCore that provides 
>> a clear porting layer. I would not expect anyone outside of WebCore to be 
>> linking to it. Because of that it was living inside Source/WebCore, and 
>> since it was setup that way having an internal namespace of WebCore::PAL 
>> made sense conceptually. Also in the future if PAL was successful I could 
>> see a WebKit2 equivalent.
>>  
>> Whatever the consensus is we’re looking forward to working on getting the 
>> PAL layer up and running. We’re working on rebooting our port so we’re in a 
>> good position to help build it out and do any refactoring to help create a 
>> clear layering. Having a clear porting layer, especially one with tests, is 
>> something we’re hoping will be beneficial to all the ports.
>>  
>> From: webkit-dev-boun...@lists.webkit.org 
>> <mailto:webkit-dev-boun...@lists.webkit.org> 
>> [mailto:webkit-dev-boun...@lists.webkit.org 
>> <mailto:webkit-dev-boun...@lists.webkit.org>] On Behalf Of Maciej Stachowiak
>> Sent: Wednesday, January 11, 2017 2:05 PM
>> To: Antti Koivisto <koivi...@iki.fi <mailto:koivi...@iki.fi>>
>> Cc: Webkit Development List <webkit-dev@lists.webkit.org 
>> <mailto:webkit-dev@lists.webkit.org>>; mrobin...@igalia.com 
>> <mailto:mrobin...@igalia.com>
>> Subject: Re: [webkit-dev] WebCore/platform standalone library
>>  
>>  
>> These both sound right to me. 
>>  
>> More generally, I would expect that over time, PAL would likely become a 
>> peer project to WebCore instead of being inside it, much the same way WTF 
>> started inside JavaScriptCore and eventually moved outside it in the source 
>> tree. In the WTF case, it always had a separate top-level namespace.
>>  
>> On Jan 11, 2017, at 12:27 PM, Antti Koivisto <koivi...@iki.fi 
>> <mailto:koivi...@iki.fi>> wrote:
>>  
>> Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a 
>> top-level namespace (even if it currently happens to live in the WebCore 
>> project)?
>>  
>> #include  would be more consistent with existing headers than 
>> .
>>  
>>  
>>   antti
>>  
>> On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield <mmaxfi...@apple.com 
>> <mailto:mmaxfi...@apple.com>> wrote:
>> After 18 months of no progress, Don Olmstead and I are getting the band back 
>> together!
>>  
>> We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 
>> <https://bugs.webkit.org/show_bug.cgi?id=143358> which incorporates feedback 
>> from many different stakeholders (and as such, the direction is a little 
>> different than where I was going with this in the beginning).
>>  
>> First of all, this isn’t a new project; instead, it’s a new target inside 
>> the WebCore project. The target creates a static library which gets linked 
>> into WebCore, which means that the enforcement mechanism can’t be done by 
>> the linker. Instead, the layering will be enforced by a Python script, 
>> triggered as an extra 

Re: [webkit-dev] WebCore/platform standalone library

[Michael Catanzaro]

On Wed, 2017-01-11 at 23:30 +, Olmstead, Don wrote:
> I had thought of PAL as a library that is internal to WebCore that
> provides a clear porting layer. I would not expect anyone outside of
> WebCore to be linking to it.

So honestly, I don't think this is very realistic. Lots of stuff
currently under WebCore/platform needs to be used by WebKit and
WebKit2. ResourceHandle, for example. Or TextChecker. These are just
the very first two that come to mind. So if we want PAL to be
completely internal to WebCore, then we're not going to be able to get
rid of WebCore/platform, and then we'll have two different platform
abstraction libraries. That does not seem desirable. Moreover, the
criterion to determine whether a class should go in PAL or platform
would then be whether the stuff needs to be accessed from WebKit layers
or not. That doesn't seem useful.

So I think we should drop that goal. (Still really excited for PAL, of
course.)

On Wed, 2017-01-11 at 23:30 +, Olmstead, Don wrote:
> Whatever the consensus is we’re looking forward to working on getting
> the PAL layer up and running. We’re working on rebooting our port so
> we’re in a good position to help build it out and do any refactoring
> to help create a clear layering. Having a clear porting layer,
> especially one with tests, is something we’re hoping will be
> beneficial to all the ports.

This is exciting to hear too!

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Maciej Stachowiak]

To be clear, I think PAL is a great move. Details like the namespace, placement 
of the code, and how includes look are all things that can be changed after the 
fact.

That said, I think we need to ultimately consider our porting layer to be the 
combination of PAL and WTF, so it is good for the two to be consistent. I hope 
revisions along these lines can be considered in due course.

Regards,
Maciej

> On Jan 11, 2017, at 3:30 PM, Olmstead, Don <don.olmst...@sony.com> wrote:
> 
> I was the one who did the WebCore::PAL namespace so I wanted to chime in on 
> why I went that route. We at Sony are newcomers to pushing to trunk so my 
> explanation might be entirely too idealistic but here goes.
>  
> I had thought of PAL as a library that is internal to WebCore that provides a 
> clear porting layer. I would not expect anyone outside of WebCore to be 
> linking to it. Because of that it was living inside Source/WebCore, and since 
> it was setup that way having an internal namespace of WebCore::PAL made sense 
> conceptually. Also in the future if PAL was successful I could see a WebKit2 
> equivalent.
>  
> Whatever the consensus is we’re looking forward to working on getting the PAL 
> layer up and running. We’re working on rebooting our port so we’re in a good 
> position to help build it out and do any refactoring to help create a clear 
> layering. Having a clear porting layer, especially one with tests, is 
> something we’re hoping will be beneficial to all the ports.
>  
> From: webkit-dev-boun...@lists.webkit.org 
> [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Maciej Stachowiak
> Sent: Wednesday, January 11, 2017 2:05 PM
> To: Antti Koivisto <koivi...@iki.fi>
> Cc: Webkit Development List <webkit-dev@lists.webkit.org>; 
> mrobin...@igalia.com
> Subject: Re: [webkit-dev] WebCore/platform standalone library
>  
>  
> These both sound right to me. 
>  
> More generally, I would expect that over time, PAL would likely become a peer 
> project to WebCore instead of being inside it, much the same way WTF started 
> inside JavaScriptCore and eventually moved outside it in the source tree. In 
> the WTF case, it always had a separate top-level namespace.
>  
> On Jan 11, 2017, at 12:27 PM, Antti Koivisto <koivi...@iki.fi 
> <mailto:koivi...@iki.fi>> wrote:
>  
> Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a 
> top-level namespace (even if it currently happens to live in the WebCore 
> project)?
>  
> #include  would be more consistent with existing headers than 
> .
>  
>  
>   antti
>  
> On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield <mmaxfi...@apple.com 
> <mailto:mmaxfi...@apple.com>> wrote:
> After 18 months of no progress, Don Olmstead and I are getting the band back 
> together!
>  
> We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 
> <https://bugs.webkit.org/show_bug.cgi?id=143358> which incorporates feedback 
> from many different stakeholders (and as such, the direction is a little 
> different than where I was going with this in the beginning).
>  
> First of all, this isn’t a new project; instead, it’s a new target inside the 
> WebCore project. The target creates a static library which gets linked into 
> WebCore, which means that the enforcement mechanism can’t be done by the 
> linker. Instead, the layering will be enforced by a Python script, triggered 
> as an extra build step, which checks the symbol names inside the .a file as 
> well as #include directives in source code.
>  
> We opted for WebCore to include files using “#include ” instead of 
> just including Foo.h. Similarly, we are putting symbols inside the PAL 
> namespace, which is a child of the WebCore namespace. Therefore, inside 
> WebCore, you use PAL things by specifying “PAL::Foo”.
>  
> The first thing to move into PAL is the “crypto” subfolder, which is a good 
> candidate because it’s small, simple, yet also has platform-dependent 
> implementations.
>  
> We would love your feedback on this approach to help make the dream a reality!
>  
> Thanks,
> Myles and Don
>  
> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough <barraclo...@apple.com 
> <mailto:barraclo...@apple.com>> wrote:
>  
> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak <m...@apple.com 
> <mailto:m...@apple.com>> wrote:
>  
> Web Abstraction Toolbox (it’s hard to tell the difference between wat and WTF 
> sometimes…)
>  
> +1
>  
>  
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://l

Re: [webkit-dev] WebCore/platform standalone library

[Olmstead, Don]

I was the one who did the WebCore::PAL namespace so I wanted to chime in on why 
I went that route. We at Sony are newcomers to pushing to trunk so my 
explanation might be entirely too idealistic but here goes.

I had thought of PAL as a library that is internal to WebCore that provides a 
clear porting layer. I would not expect anyone outside of WebCore to be linking 
to it. Because of that it was living inside Source/WebCore, and since it was 
setup that way having an internal namespace of WebCore::PAL made sense 
conceptually. Also in the future if PAL was successful I could see a WebKit2 
equivalent.

Whatever the consensus is we’re looking forward to working on getting the PAL 
layer up and running. We’re working on rebooting our port so we’re in a good 
position to help build it out and do any refactoring to help create a clear 
layering. Having a clear porting layer, especially one with tests, is something 
we’re hoping will be beneficial to all the ports.

From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Maciej Stachowiak
Sent: Wednesday, January 11, 2017 2:05 PM
To: Antti Koivisto <koivi...@iki.fi>
Cc: Webkit Development List <webkit-dev@lists.webkit.org>; mrobin...@igalia.com
Subject: Re: [webkit-dev] WebCore/platform standalone library


These both sound right to me.

More generally, I would expect that over time, PAL would likely become a peer 
project to WebCore instead of being inside it, much the same way WTF started 
inside JavaScriptCore and eventually moved outside it in the source tree. In 
the WTF case, it always had a separate top-level namespace.

On Jan 11, 2017, at 12:27 PM, Antti Koivisto 
<koivi...@iki.fi<mailto:koivi...@iki.fi>> wrote:

Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a 
top-level namespace (even if it currently happens to live in the WebCore 
project)?

#include  would be more consistent with existing headers than 
.


  antti

On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield 
<mmaxfi...@apple.com<mailto:mmaxfi...@apple.com>> wrote:
After 18 months of no progress, Don Olmstead and I are getting the band back 
together!

We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 which 
incorporates feedback from many different stakeholders (and as such, the 
direction is a little different than where I was going with this in the 
beginning).

First of all, this isn’t a new project; instead, it’s a new target inside the 
WebCore project. The target creates a static library which gets linked into 
WebCore, which means that the enforcement mechanism can’t be done by the 
linker. Instead, the layering will be enforced by a Python script, triggered as 
an extra build step, which checks the symbol names inside the .a file as well 
as #include directives in source code.

We opted for WebCore to include files using “#include ” instead of 
just including Foo.h. Similarly, we are putting symbols inside the PAL 
namespace, which is a child of the WebCore namespace. Therefore, inside 
WebCore, you use PAL things by specifying “PAL::Foo”.

The first thing to move into PAL is the “crypto” subfolder, which is a good 
candidate because it’s small, simple, yet also has platform-dependent 
implementations.

We would love your feedback on this approach to help make the dream a reality!

Thanks,
Myles and Don

On Mar 22, 2015, at 4:40 PM, Gavin Barraclough 
<barraclo...@apple.com<mailto:barraclo...@apple.com>> wrote:

On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak 
<m...@apple.com<mailto:m...@apple.com>> wrote:

Web Abstraction Toolbox (it’s hard to tell the difference between wat and WTF 
sometimes…)

+1


___
webkit-dev mailing list
webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Michael Catanzaro]

Really happy to see progress on this!

On Tue, 2017-01-10 at 21:24 -0800, Myles C. Maxfield wrote:
> First of all, this isn’t a new project; instead, it’s a new target
> inside the WebCore project. The target creates a static library which
> gets linked into WebCore, which means that the enforcement mechanism
> can’t be done by the linker. Instead, the layering will be enforced
> by a Python script, triggered as an extra build step, which checks
> the symbol names inside the .a file as well as #include directives in
> source code.

My preference remains to put PAL inside the toplevel Source/ directory
and make it a proper dependency of WebCore, because it seems far
superior to have the linker enforce layering. (A secondary concern is
that it will be nicer to say PAL::Foo rather than WebCore::PAL::Foo
when using PAL from the WebKit and WebKit2 layers.)

I appreciate that the decision to make it a target rather than a
dependency was driven by a desire to simplify the build system, and I
also appreciate that CMake and XCode are both complex beasts. But I
don't think this is the right approach. Consider that there is very
little material advantage to WebCore/PAL over the existing
WebCore/platform: we already have Tools/Scripts/check-for-platform-
layering-violations to check for platform layering violations, so the
only real advantage to adding PAL would be that PAL doesn't currently
have any such layering violations and so the layering enforcement
script could be run by the style checker. If that were the only goal,
then it would be simpler to keep WebCore/platform and just fix the
layering violations than to slowly move everything to a new directory.
I'd much rather let the linker handle layering enforcement; then there
is real value to splitting out PAL.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Michael Catanzaro]

On Tue, 2017-01-10 at 21:28 -0800, Darin Adler wrote:
> Given that WTF chose , what is the reasoning for PAL
> choosing the all capital ?

I kinda prefer  myself, in order to parallel WTF. On the one
hand, it almost doesn't matter, but on the other it's one more rule to
have to memorize which includes must be lowercase and which must be
uppercase.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Maciej Stachowiak]

These both sound right to me. 

More generally, I would expect that over time, PAL would likely become a peer 
project to WebCore instead of being inside it, much the same way WTF started 
inside JavaScriptCore and eventually moved outside it in the source tree. In 
the WTF case, it always had a separate top-level namespace.

> On Jan 11, 2017, at 12:27 PM, Antti Koivisto  wrote:
> 
> Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a 
> top-level namespace (even if it currently happens to live in the WebCore 
> project)?
> 
> #include  would be more consistent with existing headers than 
> .
> 
> 
>   antti
> 
> On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield  > wrote:
> After 18 months of no progress, Don Olmstead and I are getting the band back 
> together!
> 
> We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 
>  which incorporates feedback 
> from many different stakeholders (and as such, the direction is a little 
> different than where I was going with this in the beginning).
> 
> First of all, this isn’t a new project; instead, it’s a new target inside the 
> WebCore project. The target creates a static library which gets linked into 
> WebCore, which means that the enforcement mechanism can’t be done by the 
> linker. Instead, the layering will be enforced by a Python script, triggered 
> as an extra build step, which checks the symbol names inside the .a file as 
> well as #include directives in source code.
> 
> We opted for WebCore to include files using “#include ” instead of 
> just including Foo.h. Similarly, we are putting symbols inside the PAL 
> namespace, which is a child of the WebCore namespace. Therefore, inside 
> WebCore, you use PAL things by specifying “PAL::Foo”.
> 
> The first thing to move into PAL is the “crypto” subfolder, which is a good 
> candidate because it’s small, simple, yet also has platform-dependent 
> implementations.
> 
> We would love your feedback on this approach to help make the dream a reality!
> 
> Thanks,
> Myles and Don
> 
>> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough > > wrote:
>> 
>>> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak >> > wrote:
>>> 
>>> Web Abstraction Toolbox (it’s hard to tell the difference between wat and 
>>> WTF sometimes…)
>> 
>> +1
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Antti Koivisto]

Why is the PAL namespace inside the WebCore namespace? Couldn't it just be
a top-level namespace (even if it currently happens to live in the WebCore
project)?

#include  would be more consistent with existing headers than
.


  antti

On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield 
wrote:

> After 18 months of no progress, Don Olmstead and I are getting the band
> back together!
>
> We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 which
> incorporates feedback from many different stakeholders (and as such, the
> direction is a little different than where I was going with this in the
> beginning).
>
> First of all, this isn’t a new project; instead, it’s a new target inside
> the WebCore project. The target creates a static library which gets linked
> into WebCore, which means that the enforcement mechanism can’t be done by
> the linker. Instead, the layering will be enforced by a Python script,
> triggered as an extra build step, which checks the symbol names inside the
> .a file as well as #include directives in source code.
>
> We opted for WebCore to include files using “#include ” instead
> of just including Foo.h. Similarly, we are putting symbols inside the PAL
> namespace, which is a child of the WebCore namespace. Therefore, inside
> WebCore, you use PAL things by specifying “PAL::Foo”.
>
> The first thing to move into PAL is the “crypto” subfolder, which is a
> good candidate because it’s small, simple, yet also has platform-dependent
> implementations.
>
> We would love your feedback on this approach to help make the dream a
> reality!
>
> Thanks,
> Myles and Don
>
> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough 
> wrote:
>
> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak  wrote:
>
> Web Abstraction Toolbox (it’s hard to tell the difference between wat and
> WTF sometimes…)
>
>
> +1
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

On Jan 10, 2017, at 9:28 PM, Darin Adler  wrote:

>> On Jan 10, 2017, at 9:24 PM, Myles C. Maxfield  wrote:
>> 
>> We opted for WebCore to include files using “#include ” instead 
>> of just including Foo.h.
> 
> Will this work without ForwardingHeaders on macOS and iOS?

I think this requires more investigation to answer. 

> 
> Given that WTF chose , what is the reasoning for PAL choosing the 
> all capital ?

Beauty. Do you think this was a bad call?

> 
>> Similarly, we are putting symbols inside the PAL namespace, which is a child 
>> of the WebCore namespace. Therefore, inside WebCore, you use PAL things by 
>> specifying “PAL::Foo”.
> 
> Given that WebCore is built on top of PAL, it seems a little strange to put 
> PAL “inside” WebCore, but I guess OK.

Yeah, this was driven by the decision to make it a target rather than a 
project. Putting a target of a project outside the project itself seems worse 
than putting a dependency inside the project.

> 
> — Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

> On Jan 10, 2017, at 11:08 PM, Carlos Garcia Campos  
> wrote:
> 
>> El mar, 10-01-2017 a las 21:24 -0800, Myles C. Maxfield escribió:
>> After 18 months of no progress, Don Olmstead and I are getting the
>> band back together!
> 
> Great news. 
> 
>> We’ve uploaded a patch
>> to https://bugs.webkit.org/show_bug.cgi?id=143358 which incorporates
>> feedback from many different stakeholders (and as such, the direction
>> is a little different than where I was going with this in the
>> beginning).
>> 
>> First of all, this isn’t a new project; instead, it’s a new target
>> inside the WebCore project. The target creates a static library which
>> gets linked into WebCore, which means that the enforcement mechanism
>> can’t be done by the linker. Instead, the layering will be enforced
>> by a Python script, triggered as an extra build step, which checks
>> the symbol names inside the .a file as well as #include directives in
>> source code.
> 
> So, will it be possible to link to PAL but not the rest of WebCore?

Yes. This is the testing strategy. A goal is to be able to unit-test PAL 
without a layout test.

> 
>> We opted for WebCore to include files using “#include ”
>> instead of just including Foo.h. Similarly, we are putting symbols
>> inside the PAL namespace, which is a child of the WebCore namespace.
>> Therefore, inside WebCore, you use PAL things by specifying
>> “PAL::Foo”.
> 
> And WebCore::PAL::Foo when used outside WebCore namespace, right?

✅

> 
>> The first thing to move into PAL is the “crypto” subfolder, which is
>> a good candidate because it’s small, simple, yet also has platform-
>> dependent implementations.
>> 
>> We would love your feedback on this approach to help make the dream a
>> reality!
> 
> I'm not sure I agree with the approach because I don't know the reasons
> to make it a target inside WebCore, could you elaborate more on that,
> please?

Build systems are already very complicated; we want fewer projects, not more of 
them. Also there's so complexity with ForwardingHeaders, which I'd like to 
avoid. We can achieve our objectives in the most simple way possible; no 
project is necessary. If, one day, we want PAL to be promoted to a project, we 
can do that then.

> 
>> Thanks,
>> Myles and Don
>> 
>>> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough >> om> wrote:
>>> 
 On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak 
 wrote:
 
 Web Abstraction Toolbox (it’s hard to tell the difference between
 wat and WTF sometimes…)
>>> 
>>> +1
>>> 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Carlos Garcia Campos]

El mar, 10-01-2017 a las 21:24 -0800, Myles C. Maxfield escribió:
> After 18 months of no progress, Don Olmstead and I are getting the
> band back together!

Great news. 

> We’ve uploaded a patch
> to https://bugs.webkit.org/show_bug.cgi?id=143358 which incorporates
> feedback from many different stakeholders (and as such, the direction
> is a little different than where I was going with this in the
> beginning).
> 
> First of all, this isn’t a new project; instead, it’s a new target
> inside the WebCore project. The target creates a static library which
> gets linked into WebCore, which means that the enforcement mechanism
> can’t be done by the linker. Instead, the layering will be enforced
> by a Python script, triggered as an extra build step, which checks
> the symbol names inside the .a file as well as #include directives in
> source code.

So, will it be possible to link to PAL but not the rest of WebCore?

> We opted for WebCore to include files using “#include ”
> instead of just including Foo.h. Similarly, we are putting symbols
> inside the PAL namespace, which is a child of the WebCore namespace.
> Therefore, inside WebCore, you use PAL things by specifying
> “PAL::Foo”.

And WebCore::PAL::Foo when used outside WebCore namespace, right?

> The first thing to move into PAL is the “crypto” subfolder, which is
> a good candidate because it’s small, simple, yet also has platform-
> dependent implementations.
> 
> We would love your feedback on this approach to help make the dream a
> reality!

I'm not sure I agree with the approach because I don't know the reasons
 to make it a target inside WebCore, could you elaborate more on that,
please?

> Thanks,
> Myles and Don
> 
> > On Mar 22, 2015, at 4:40 PM, Gavin Barraclough  > om> wrote:
> > 
> > > On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak 
> > > wrote:
> > > 
> > > Web Abstraction Toolbox (it’s hard to tell the difference between
> > > wat and WTF sometimes…)
> > 
> > +1
> > 
> > 
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Darin Adler]

> On Jan 10, 2017, at 9:24 PM, Myles C. Maxfield  wrote:
> 
> We opted for WebCore to include files using “#include ” instead of 
> just including Foo.h.

Will this work without ForwardingHeaders on macOS and iOS?

Given that WTF chose , what is the reasoning for PAL choosing the 
all capital ?

> Similarly, we are putting symbols inside the PAL namespace, which is a child 
> of the WebCore namespace. Therefore, inside WebCore, you use PAL things by 
> specifying “PAL::Foo”.

Given that WebCore is built on top of PAL, it seems a little strange to put PAL 
“inside” WebCore, but I guess OK.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

After 18 months of no progress, Don Olmstead and I are getting the band back 
together!

We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 
 which incorporates feedback 
from many different stakeholders (and as such, the direction is a little 
different than where I was going with this in the beginning).

First of all, this isn’t a new project; instead, it’s a new target inside the 
WebCore project. The target creates a static library which gets linked into 
WebCore, which means that the enforcement mechanism can’t be done by the 
linker. Instead, the layering will be enforced by a Python script, triggered as 
an extra build step, which checks the symbol names inside the .a file as well 
as #include directives in source code.

We opted for WebCore to include files using “#include ” instead of 
just including Foo.h. Similarly, we are putting symbols inside the PAL 
namespace, which is a child of the WebCore namespace. Therefore, inside 
WebCore, you use PAL things by specifying “PAL::Foo”.

The first thing to move into PAL is the “crypto” subfolder, which is a good 
candidate because it’s small, simple, yet also has platform-dependent 
implementations.

We would love your feedback on this approach to help make the dream a reality!

Thanks,
Myles and Don

> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough  > wrote:
> 
>> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak > > wrote:
>> 
>> Web Abstraction Toolbox (it’s hard to tell the difference between wat and 
>> WTF sometimes…)
> 
> +1
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Gavin Barraclough]

 On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak m...@apple.com wrote:
 
 Web Abstraction Toolbox (it’s hard to tell the difference between wat and WTF 
 sometimes…)

+1


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

I think we have a winner!

 If I suggest one.. how about WAFL? WebCore Abstraction Framework Layer
 It should sound sweet like waffle =)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Maciej Stachowiak]

We’ll have times when we need to decide what goes into this library, and what 
goes into WTF. So I like the ones that fit the sentence “Is this really WTF or 
is it just __?”

LOL, ROFL and ROFLCOPTER work well for this. I would also suggest:

Web Abstraction Toolbox (it’s hard to tell the difference between wat and WTF 
sometimes…)


 On Mar 21, 2015, at 8:53 AM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 I think we have a winner!
 
 If I suggest one.. how about WAFL? WebCore Abstraction Framework Layer
 It should sound sweet like waffle =)
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[ChangSeok Oh]

 Low-level Object Library.

This sounds good to me. Something prefixed “NEW” could not be new forever. ;)
If I suggest one.. how about WAFL? WebKit(or WebCore) Abstraction Framework 
Library(or Layer)
It should sound sweet like waffle =)

ChangSeok

 On Mar 21, 2015, at 3:26 AM, Simon Fraser simon.fra...@apple.com wrote:
 
 
 On Mar 20, 2015, at 11:03 AM, Edward O'Connor eocon...@apple.com 
 mailto:eocon...@apple.com wrote:
 
  This almost makes me want to suggest a jokey name for Platform. I can’t 
  off the top of my head think of a good expansion of OMG, though. Or BBQ.
 
  I am not a pro at this, but here are a few tries: Lower-level Object 
  Library. Algorithm Reuse Framework. New Framework for WebCore, New System 
  Framework for WebCore.
 
 Platform Obfuscation Source.
 
 Platform Interface and Testing Abstraction.
 
 General Independent Framework (pronounced jiff, of course).
 
 Low-Level Abstract Platform would also be a logical choice.
 
 Low-level Object Library.
 
 Simon
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Gyuyoung Kim]

Platform Interface and Testing Abstraction.

- R. Niwa

*P*latform *A*bstract *I*nterface ? Sound like delicious pie :)

Gyuyoung


On Sat, Mar 21, 2015 at 2:18 AM, Ryosuke Niwa rn...@webkit.org wrote:



 On Friday, March 20, 2015, Simon Fraser simon.fra...@apple.com wrote:

 On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote:

  On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote:
 
  This almost makes me want to suggest a jokey name for Platform. I
 can’t off the top of my head think of a good expansion of OMG, though. Or
 BBQ.
 
  I am not a pro at this, but here are a few tries: Lower-level Object
 Library. Algorithm Reuse Framework. New Framework for WebCore, New System
 Framework for WebCore.

 Platform Obfuscation Source.


 Platform Interface and Testing Abstraction.

 - R. Niwa







 --
 - R. Niwa

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Antti Koivisto]

Reusable Os Fitting Layer


   antti

On Fri, Mar 20, 2015 at 11:26 AM, Simon Fraser simon.fra...@apple.com
wrote:


 On Mar 20, 2015, at 11:03 AM, Edward O'Connor eocon...@apple.com wrote:

  This almost makes me want to suggest a jokey name for Platform. I can’t
 off the top of my head think of a good expansion of OMG, though. Or BBQ.
 
  I am not a pro at this, but here are a few tries: Lower-level Object
 Library. Algorithm Reuse Framework. New Framework for WebCore, New System
 Framework for WebCore.

 Platform Obfuscation Source.


 Platform Interface and Testing Abstraction.


 General Independent Framework (pronounced jiff, of course).

 Low-Level Abstract Platform would also be a logical choice.


 Low-level Object Library.

 Simon


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Simon Fraser]

 On Mar 20, 2015, at 11:03 AM, Edward O'Connor eocon...@apple.com wrote:
 
  This almost makes me want to suggest a jokey name for Platform. I can’t 
  off the top of my head think of a good expansion of OMG, though. Or BBQ.
 
  I am not a pro at this, but here are a few tries: Lower-level Object 
  Library. Algorithm Reuse Framework. New Framework for WebCore, New System 
  Framework for WebCore.
 
 Platform Obfuscation Source.
 
 Platform Interface and Testing Abstraction.
 
 General Independent Framework (pronounced jiff, of course).
 
 Low-Level Abstract Platform would also be a logical choice.

Low-level Object Library.

Simon

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Edward O'Connor]

  This almost makes me want to suggest a jokey name for Platform. I can’t 
  off the top of my head think of a good expansion of OMG, though. Or BBQ.
 
  I am not a pro at this, but here are a few tries: Lower-level Object 
  Library. Algorithm Reuse Framework. New Framework for WebCore, New System 
  Framework for WebCore.
 
 Platform Obfuscation Source.
 
 Platform Interface and Testing Abstraction.

General Independent Framework (pronounced jiff, of course).

Low-Level Abstract Platform would also be a logical choice.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Ryosuke Niwa]

On Friday, March 20, 2015, Simon Fraser simon.fra...@apple.com wrote:

 On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com javascript:;
 wrote:

  On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com
 javascript:; wrote:
 
  This almost makes me want to suggest a jokey name for Platform. I can't
 off the top of my head think of a good expansion of OMG, though. Or BBQ.
 
  I am not a pro at this, but here are a few tries: Lower-level Object
 Library. Algorithm Reuse Framework. New Framework for WebCore, New System
 Framework for WebCore.

 Platform Obfuscation Source.


Platform Interface and Testing Abstraction.

- R. Niwa







-- 
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Nico Weber]

On Fri, Mar 20, 2015 at 9:56 AM, Simon Fraser simon.fra...@apple.com
wrote:

 On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote:

  On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote:
 
  This almost makes me want to suggest a jokey name for Platform. I can’t
 off the top of my head think of a good expansion of OMG, though. Or BBQ.
 
  I am not a pro at this, but here are a few tries: Lower-level Object
 Library. Algorithm Reuse Framework. New Framework for WebCore, New System
 Framework for WebCore.

 Platform Obfuscation Source.


Web Utility Belt With Useful Behavior.



 Simon

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Darin Adler]

 On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote:
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.

I am not a pro at this, but here are a few tries: Lower-level Object Library. 
Algorithm Reuse Framework. New Framework for WebCore, New System Framework for 
WebCore.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Filip Pizlo]

 On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote:
 
 New System Framework for WebCore

This!

-Filip
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Simon Fraser]

On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote:

 On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote:
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.
 
 I am not a pro at this, but here are a few tries: Lower-level Object Library. 
 Algorithm Reuse Framework. New Framework for WebCore, New System Framework 
 for WebCore.

Platform Obfuscation Source.

Simon

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Jer Noble]

 On Mar 20, 2015, at 11:40 AM, Antti Koivisto koivi...@iki.fi wrote:
 
 Reusable Os Fitting Layer

…Containing Opensource Platform Types, Events, and Resources.

-Jer

 
 
antti
 
 On Fri, Mar 20, 2015 at 11:26 AM, Simon Fraser simon.fra...@apple.com 
 mailto:simon.fra...@apple.com wrote:
 
 On Mar 20, 2015, at 11:03 AM, Edward O'Connor eocon...@apple.com 
 mailto:eocon...@apple.com wrote:
 
  This almost makes me want to suggest a jokey name for Platform. I can’t 
  off the top of my head think of a good expansion of OMG, though. Or BBQ.
 
  I am not a pro at this, but here are a few tries: Lower-level Object 
  Library. Algorithm Reuse Framework. New Framework for WebCore, New System 
  Framework for WebCore.
 
 Platform Obfuscation Source.
 
 Platform Interface and Testing Abstraction.
 
 General Independent Framework (pronounced jiff, of course).
 
 Low-Level Abstract Platform would also be a logical choice.
 
 Low-level Object Library.
 
 Simon
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Carlos Garcia Campos]

El mié, 18-03-2015 a las 21:43 -0700, Myles C. Maxfield escribió:
 Hello, all,
 
 I’d like to announce that I intend to create a standalone static library from 
 the current contents of WebCore/platform over the coming months. This will 
 involve creating a “Platform top-level directory and moving source files 
 into it, one by one. 

Yes!

 There are a few reasons for this:
 
 1. Enforcing the layering between Platform and WebCore. Moving Platform into 
 its own target/directory can guarantee that nothing inside it knows about 
 anything in WebCore.
 2. Being able to test code in the Platform directory with TestWebKitAPI 
 (without exporting Platform symbols from the WebCore library)
 3. Managing conceptual complexity.
 
 Does anyone have any thoughts or feedback?

This has always been blocked by the existing layering violations, what
are your plans for that? I guess we will have WebCore/platform and
Platform at the same time for a while until all layering violations are
fixed?

See the tracking bug:
https://bugs.webkit.org/show_bug.cgi?id=21354

But there are more, I wrote a script to get the list of violations, it's
in Tools/Scripts/check-for-platform-layering-violations

 Thanks,
 Myles
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[saam barati]

I think JavaScriptCore will need access to 'platform', too, to implement some 
ES6 features. 




Saam

On Thu, Mar 19, 2015 at 2:50 PM, Maciej Stachowiak m...@apple.com wrote:

 On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
 Hello, all,
 
 I’d like to announce that I intend to create a standalone static library 
 from the current contents of WebCore/platform over the coming months. This 
 will involve creating a “Platform top-level directory and moving source 
 files into it, one by one.
 
 There are a few reasons for this:
 
 1. Enforcing the layering between Platform and WebCore. Moving Platform 
 into its own target/directory can guarantee that nothing inside it knows 
 about anything in WebCore.
 2. Being able to test code in the Platform directory with TestWebKitAPI 
 (without exporting Platform symbols from the WebCore library)
 3. Managing conceptual complexity.
 
 Does anyone have any thoughts or feedback?
 
 That's an awesome project. That's gonna be a lot of work.
 
 How do you plan to do the interface between WebCore and Platform?
 
 Between WebCore and WebKit, we use interfaces with pure virtual functions 
 that are implemented by the clients.
 Between WebCore and the platform, we have headers and each port has its own 
 implementation of that interface.
 
 Do you plan to move Platform behind a public interface or keep the current 
 model?
 I don’t think we need a model like the WebCore/WebKit interface. WTF is 
 essentially like the proposed Platform library already, and it just exposes 
 normal C++ headers and implementation files. I think the main benefit here is 
 cleaning up the layering, as opposed to adding more abstraction. In fact, you 
 could sort of think of WTF and Platform as logically the same library, with 
 WTF being only the parts needed by JavaScriptCore, plus things that are 
 logically at the same level (so basically non-GUI and no networking code).
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.
 Regards,
 Maciej
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Maciej Stachowiak]

 On Mar 19, 2015, at 3:44 PM, saam barati saambara...@gmail.com wrote:
 
 I think JavaScriptCore will need access to 'platform', too, to implement some 
 ES6 features. 

Anything needed for JavaScriptCore should go to WTF. Otherwise there is no 
point having a separation.

 - Maciej

 
 Saam
 
 
 On Thu, Mar 19, 2015 at 2:50 PM, Maciej Stachowiak m...@apple.com 
 mailto:m...@apple.com wrote:
 
 
  On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote:
  
  On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
  Hello, all,
  
  I’d like to announce that I intend to create a standalone static library 
  from the current contents of WebCore/platform over the coming months. This 
  will involve creating a “Platform top-level directory and moving source 
  files into it, one by one.
  
  There are a few reasons for this:
  
  1. Enforcing the layering between Platform and WebCore. Moving Platform 
  into its own target/directory can guarantee that nothing inside it knows 
  about anything in WebCore.
  2. Being able to test code in the Platform directory with TestWebKitAPI 
  (without exporting Platform symbols from the WebCore library)
  3. Managing conceptual complexity.
  
  Does anyone have any thoughts or feedback?
  
  That's an awesome project. That's gonna be a lot of work.
  
  How do you plan to do the interface between WebCore and Platform?
  
  Between WebCore and WebKit, we use interfaces with pure virtual functions 
  that are implemented by the clients.
  Between WebCore and the platform, we have headers and each port has its own 
  implementation of that interface.
  
  Do you plan to move Platform behind a public interface or keep the current 
  model?
 
 I don’t think we need a model like the WebCore/WebKit interface. WTF is 
 essentially like the proposed Platform library already, and it just exposes 
 normal C++ headers and implementation files. I think the main benefit here is 
 cleaning up the layering, as opposed to adding more abstraction. In fact, you 
 could sort of think of WTF and Platform as logically the same library, with 
 WTF being only the parts needed by JavaScriptCore, plus things that are 
 logically at the same level (so basically non-GUI and no networking code).
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.
 
 Regards,
 Maciej
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Maciej Stachowiak]

 On Mar 19, 2015, at 5:19 PM, Anders Carlsson ander...@apple.com wrote:
 
 
 On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com 
 mailto:m...@apple.com wrote:
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.
 
 I think putting platform code in a separate namespace would be a good first 
 step. Then we can weed out the layering violations and ultimately move 
 everything to a separate library.

I think it would also be fine to start by moving every file that doesn’t 
contain a layering violation and then fix the remainder. Moving the files could 
be done together with changing the namespace, or as a separate pass.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Benjamin Poulain]

On 3/19/15 2:49 PM, Maciej Stachowiak wrote:



On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote:

On 3/18/15 9:43 PM, Myles C. Maxfield wrote:

Hello, all,

I’d like to announce that I intend to create a standalone static library from the 
current contents of WebCore/platform over the coming months. This will involve 
creating a “Platform top-level directory and moving source files into it, one 
by one.

There are a few reasons for this:

1. Enforcing the layering between Platform and WebCore. Moving Platform into 
its own target/directory can guarantee that nothing inside it knows about 
anything in WebCore.
2. Being able to test code in the Platform directory with TestWebKitAPI 
(without exporting Platform symbols from the WebCore library)
3. Managing conceptual complexity.

Does anyone have any thoughts or feedback?


That's an awesome project. That's gonna be a lot of work.

How do you plan to do the interface between WebCore and Platform?

Between WebCore and WebKit, we use interfaces with pure virtual functions that 
are implemented by the clients.
Between WebCore and the platform, we have headers and each port has its own 
implementation of that interface.

Do you plan to move Platform behind a public interface or keep the current 
model?


I don’t think we need a model like the WebCore/WebKit interface. WTF is 
essentially like the proposed Platform library already, and it just exposes 
normal C++ headers and implementation files. I think the main benefit here is 
cleaning up the layering, as opposed to adding more abstraction. In fact, you 
could sort of think of WTF and Platform as logically the same library, with WTF 
being only the parts needed by JavaScriptCore, plus things that are logically 
at the same level (so basically non-GUI and no networking code).

This almost makes me want to suggest a jokey name for Platform. I can’t off the 
top of my head think of a good expansion of OMG, though. Or BBQ.


Have you seen the clean interface of ResourceHandle? :)

The client layers tend to get cleaner over time while the lower layers 
tends to become messier.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Anders Carlsson]

 On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote:
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.

I think putting platform code in a separate namespace would be a good first 
step. Then we can weed out the layering violations and ultimately move 
everything to a separate library.

- Anders (who’s not going to propose any namespace names)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

I do not intend on changing any interfaces or semantics. I only intend to 
change where code lives and library boundaries. There is no need to increase 
the scope of this project.

Also, I do not intend on making up a comical name.

--Myles

 On Mar 19, 2015, at 3:03 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 3/19/15 2:49 PM, Maciej Stachowiak wrote:
 
 On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
 Hello, all,
 
 I’d like to announce that I intend to create a standalone static library 
 from the current contents of WebCore/platform over the coming months. This 
 will involve creating a “Platform top-level directory and moving source 
 files into it, one by one.
 
 There are a few reasons for this:
 
 1. Enforcing the layering between Platform and WebCore. Moving Platform 
 into its own target/directory can guarantee that nothing inside it knows 
 about anything in WebCore.
 2. Being able to test code in the Platform directory with TestWebKitAPI 
 (without exporting Platform symbols from the WebCore library)
 3. Managing conceptual complexity.
 
 Does anyone have any thoughts or feedback?
 
 That's an awesome project. That's gonna be a lot of work.
 
 How do you plan to do the interface between WebCore and Platform?
 
 Between WebCore and WebKit, we use interfaces with pure virtual functions 
 that are implemented by the clients.
 Between WebCore and the platform, we have headers and each port has its own 
 implementation of that interface.
 
 Do you plan to move Platform behind a public interface or keep the current 
 model?
 
 I don’t think we need a model like the WebCore/WebKit interface. WTF is 
 essentially like the proposed Platform library already, and it just exposes 
 normal C++ headers and implementation files. I think the main benefit here 
 is cleaning up the layering, as opposed to adding more abstraction. In fact, 
 you could sort of think of WTF and Platform as logically the same library, 
 with WTF being only the parts needed by JavaScriptCore, plus things that are 
 logically at the same level (so basically non-GUI and no networking code).
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.
 
 Have you seen the clean interface of ResourceHandle? :)
 
 The client layers tend to get cleaner over time while the lower layers tends 
 to become messier.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

Sorry, I missed some of this thread before sending my reply. 

First, I'm going to try to get as far as I can by only moving over the 
non-layer-violating code. Therefore, for the interim, we will have both old and 
new directories. Then I will work on removing layering violations, one by one. 
These things will be taken on a case by case basis.

--Myles

 On Mar 19, 2015, at 10:07 PM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 I do not intend on changing any interfaces or semantics. I only intend to 
 change where code lives and library boundaries. There is no need to increase 
 the scope of this project.
 
 Also, I do not intend on making up a comical name.
 
 --Myles
 
 On Mar 19, 2015, at 3:03 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 3/19/15 2:49 PM, Maciej Stachowiak wrote:
 
 On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
 Hello, all,
 
 I’d like to announce that I intend to create a standalone static library 
 from the current contents of WebCore/platform over the coming months. 
 This will involve creating a “Platform top-level directory and moving 
 source files into it, one by one.
 
 There are a few reasons for this:
 
 1. Enforcing the layering between Platform and WebCore. Moving Platform 
 into its own target/directory can guarantee that nothing inside it knows 
 about anything in WebCore.
 2. Being able to test code in the Platform directory with TestWebKitAPI 
 (without exporting Platform symbols from the WebCore library)
 3. Managing conceptual complexity.
 
 Does anyone have any thoughts or feedback?
 
 That's an awesome project. That's gonna be a lot of work.
 
 How do you plan to do the interface between WebCore and Platform?
 
 Between WebCore and WebKit, we use interfaces with pure virtual functions 
 that are implemented by the clients.
 Between WebCore and the platform, we have headers and each port has its 
 own implementation of that interface.
 
 Do you plan to move Platform behind a public interface or keep the current 
 model?
 
 I don’t think we need a model like the WebCore/WebKit interface. WTF is 
 essentially like the proposed Platform library already, and it just exposes 
 normal C++ headers and implementation files. I think the main benefit here 
 is cleaning up the layering, as opposed to adding more abstraction. In 
 fact, you could sort of think of WTF and Platform as logically the same 
 library, with WTF being only the parts needed by JavaScriptCore, plus 
 things that are logically at the same level (so basically non-GUI and no 
 networking code).
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.
 
 Have you seen the clean interface of ResourceHandle? :)
 
 The client layers tend to get cleaner over time while the lower layers tends 
 to become messier.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Benjamin Poulain]

On 3/18/15 9:43 PM, Myles C. Maxfield wrote:

Hello, all,

I’d like to announce that I intend to create a standalone static library from the 
current contents of WebCore/platform over the coming months. This will involve 
creating a “Platform top-level directory and moving source files into it, one 
by one.

There are a few reasons for this:

1. Enforcing the layering between Platform and WebCore. Moving Platform into 
its own target/directory can guarantee that nothing inside it knows about 
anything in WebCore.
2. Being able to test code in the Platform directory with TestWebKitAPI 
(without exporting Platform symbols from the WebCore library)
3. Managing conceptual complexity.

Does anyone have any thoughts or feedback?


That's an awesome project. That's gonna be a lot of work.

How do you plan to do the interface between WebCore and Platform?

Between WebCore and WebKit, we use interfaces with pure virtual 
functions that are implemented by the clients.
Between WebCore and the platform, we have headers and each port has its 
own implementation of that interface.


Do you plan to move Platform behind a public interface or keep the 
current model?




Thanks,
Myles
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Maciej Stachowiak]

 On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
 Hello, all,
 
 I’d like to announce that I intend to create a standalone static library 
 from the current contents of WebCore/platform over the coming months. This 
 will involve creating a “Platform top-level directory and moving source 
 files into it, one by one.
 
 There are a few reasons for this:
 
 1. Enforcing the layering between Platform and WebCore. Moving Platform into 
 its own target/directory can guarantee that nothing inside it knows about 
 anything in WebCore.
 2. Being able to test code in the Platform directory with TestWebKitAPI 
 (without exporting Platform symbols from the WebCore library)
 3. Managing conceptual complexity.
 
 Does anyone have any thoughts or feedback?
 
 That's an awesome project. That's gonna be a lot of work.
 
 How do you plan to do the interface between WebCore and Platform?
 
 Between WebCore and WebKit, we use interfaces with pure virtual functions 
 that are implemented by the clients.
 Between WebCore and the platform, we have headers and each port has its own 
 implementation of that interface.
 
 Do you plan to move Platform behind a public interface or keep the current 
 model?

I don’t think we need a model like the WebCore/WebKit interface. WTF is 
essentially like the proposed Platform library already, and it just exposes 
normal C++ headers and implementation files. I think the main benefit here is 
cleaning up the layering, as opposed to adding more abstraction. In fact, you 
could sort of think of WTF and Platform as logically the same library, with WTF 
being only the parts needed by JavaScriptCore, plus things that are logically 
at the same level (so basically non-GUI and no networking code).

This almost makes me want to suggest a jokey name for Platform. I can’t off the 
top of my head think of a good expansion of OMG, though. Or BBQ.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Ryosuke Niwa]

On Wed, Mar 18, 2015 at 9:43 PM, Myles C. Maxfield mmaxfi...@apple.com
wrote:

 I'd like to announce that I intend to create a standalone static library
 from the current contents of WebCore/platform over the coming months. This
 will involve creating a Platform top-level directory and moving source
 files into it, one by one.


That sounds great.

There are a few reasons for this:

 1. Enforcing the layering between Platform and WebCore. Moving Platform
 into its own target/directory can guarantee that nothing inside it knows
 about anything in WebCore.
 2. Being able to test code in the Platform directory with TestWebKitAPI
 (without exporting Platform symbols from the WebCore library)


We should make sure unit tests we write for the Platform API doesn't reduce
the hackability / refactor-ability of the code.  It's very easy to write a
lot of unit tests around an internal API that prevent large architectual
changes.  Just look at webkitpy!  It's impossible to hack on that codebase
due to thousands of unit tests that depend on non-public API.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev