[webkit-dev] PAL Strategy

Maciej Stachowiak mjs at apple.com
Mon May 1 14:27:24 PDT 2017



> On May 1, 2017, at 1:48 PM, Brady Eidson <beidson at apple.com> wrote:
> 
> 
>> On May 1, 2017, at 12:41 PM, Michael Catanzaro <mcatanzaro at igalia.com> wrote:
>> 
>> I thought the original intent for PAL was to replace WebCore/platform, so I assume the criterion would be "stuff currently in WebCore/platform." If not, then I'd question the value of having PAL at all, as we really don't need a separate PAL on top of the platform abstraction library we already have under in Source/WebCore/platform.

I don't think anyone proposed that PAL should be on top of WebCore/platform. Instead, the question is if some things should be moved to WTF instead of to PAL. PAL is allowed to depend on WTF. JavaScriptCore is allowed to depend on WTF but not on PAL. This means that some things might be ok to put in either WTF or PAL.

>> 
>> The stuff that moved to WTF was needed in JSC. If we want to keep stuff like UUID from moving to WTF, then we'd need to allow JSC to depend on PAL, rather than vice-versa.
> 
> I think everything in WebCore/platform should be moved to PAL.
> 
> WTF should only be for things JSC needs, which is nothing inside WebCore/platform.
> 
> If JSC later needs something that is in PAL, we can move it from PAL to WTF as needed.


My 2c:

Things with no additional dependencies beyond what WTF has already might be ok to move to WTF, but it's not required to do so. For example, WTF has most of our implementations of container types, so more like those would be ok. I think it already has some that are only used in WebCore not in JSC.

Things that introduce new dependencies probably should not be moved. I think FileSystem would imply new dependencies on file operations which I don't think are currently used in WTF. The exception would be if JSC needs it for some reason.

Dependency on GUI toolkits would definitely be a hard no for WTF, since we want JSC to be independent of that.

Regards,
Maciej





More information about the webkit-dev mailing list