Bug 175471

Created attachment 317911 [details] Patch

Attachment 317911 [details] did not pass style-queue: ERROR: Source/WTF/wtf/CMakeLists.txt:278: No trailing spaces [whitespace/trailing] [5] ERROR: Source/WTF/ChangeLog:11: Need whitespace between colon and description [changelog/filechangedescriptionwhitespace] [5] Total errors found: 2 in 13 files If any of these errors are false positives, please file a bug against check-webkit-style.

What are they going to be used for in WebCore?

(In reply to Sam Weinig from comment #3) > What are they going to be used for in WebCore? ServiceWorker stuff.

Created attachment 317915 [details] Patch

(In reply to Brady Eidson from comment #4) > (In reply to Sam Weinig from comment #3) > > What are they going to be used for in WebCore? > > ServiceWorker stuff. I gathered. But why specifically will the coders be needed in WebCore? Are they for IPC? If so, why not follow the existing pattern of putting the coders in WebKit?

(In reply to Sam Weinig from comment #6) > (In reply to Brady Eidson from comment #4) > > (In reply to Sam Weinig from comment #3) > > > What are they going to be used for in WebCore? > > > > ServiceWorker stuff. > > I gathered. But why specifically will the coders be needed in WebCore? Are > they for IPC? If so, why not follow the existing pattern of putting the > coders in WebKit? I don't need the convenience of autogeneration, IPC message names and targets, etc., and by keeping everything under WebCore implementation will be lower friction and faster.

(In reply to Brady Eidson from comment #7) > (In reply to Sam Weinig from comment #6) > > (In reply to Brady Eidson from comment #4) > > > (In reply to Sam Weinig from comment #3) > > > > What are they going to be used for in WebCore? > > > > > > ServiceWorker stuff. > > > > I gathered. But why specifically will the coders be needed in WebCore? Are > > they for IPC? If so, why not follow the existing pattern of putting the > > coders in WebKit? > > I don't need the convenience of autogeneration, IPC message names and > targets, etc., and by keeping everything under WebCore implementation will > be lower friction and faster. So it's not for IPC? What's it for then? Sorry for being slow here, just don't quite get it.

(In reply to Sam Weinig from comment #8) > (In reply to Brady Eidson from comment #7) > > (In reply to Sam Weinig from comment #6) > > > (In reply to Brady Eidson from comment #4) > > > > (In reply to Sam Weinig from comment #3) > > > > > What are they going to be used for in WebCore? > > > > > > > > ServiceWorker stuff. > > > > > > I gathered. But why specifically will the coders be needed in WebCore? Are > > > they for IPC? If so, why not follow the existing pattern of putting the > > > coders in WebKit? > > > > I don't need the convenience of autogeneration, IPC message names and > > targets, etc., and by keeping everything under WebCore implementation will > > be lower friction and faster. > > So it's not for IPC? What's it for then? Sorry for being slow here, just > don't quite get it. It is for IPC. And it is for avoiding having to go up into WebKit and having to rebuild it each time I make a change that should be localized within WebCore. I am writing patches with small changes in WebCore alone that result in a sub-minute build-link time of WebCore itself. By relying on "the way things have been" with WebKit2 being the sole arbiter of encoding, my build time skyrockets by having to regenerate messages, rebuild using templated encoders from WebKit2, occasionally rebuild the entire WebKit2 world, stub out new methods, fix link errors, etc etc. Changes that should be rapid to develop instead slow me down. Significantly. I can structure significant amounts of code that rely on a single, never-changing message and encoder/decoder pair inside WebKit2, where the meat of the payload can change as needed by solely being encoded/decoded inside WebCore. This patch is about significantly reducing unnecessary friction in development, and also results in code all being localized to one project instead of spread out over two.

The alternate coding idiom, that requires less multiframework hopping, that's been used in the past is to add templatizd encode/decode functions to the classes/structs you want participate in coding. For instance, RealtimeMediaSourceSettings uses: template<class Encoder> void encode(Encoder&) const; template<class Decoder> static bool decode(Decoder&, RealtimeMediaSourceSettings&); Then, when IPC does happen, whatever message wants to code these can do so without the help of WebCoreArgumentCoders. The downside of course is that you need to declare them in the header. I hope either of these alternate strategies.

(In reply to Sam Weinig from comment #10) > The alternate coding idiom, that requires less multiframework hopping, > that's been used in the past is to add templatizd encode/decode functions to > the classes/structs you want participate in coding. For instance, > RealtimeMediaSourceSettings uses: > > template<class Encoder> void encode(Encoder&) const; > template<class Decoder> static bool decode(Decoder&, > RealtimeMediaSourceSettings&); > > Then, when IPC does happen, whatever message wants to code these can do so > without the help of WebCoreArgumentCoders. I'm an extreme champion of this technique. I'm intimately familiar with it. If you look at IDB, for example, you'll notice extensive use is made of it there. I've also added it to tons of PAL classes, have moved many WebCoreArgumentCoders from WK to WC, and have converted many other engineers on the project to it. I know about it. > The downside of course is that you need to declare them in the header. *AND* go rebuild WK2 after you've made the WebCore change. > I hope either of these alternate strategies. AFAIK, you just presented one alternate strategy, not two. --- Are you r-'ing this patch based on your feedback that there is an existing way to do things, albeit much slower to rapidly develop with? I would like to move on with development of the actual feature one way or the other.

(In reply to Brady Eidson from comment #11) > (In reply to Sam Weinig from comment #10) > > I hope either of these alternate strategies. > > AFAIK, you just presented one alternate strategy, not two. > Indeed. One. I thought I had mentioned using WebCore argument coders in WebKit as well, but it seems I didn't. Sorry for the confusion. > --- > > Are you r-'ing this patch based on your feedback that there is an existing > way to do things, albeit much slower to rapidly develop with? > > I would like to move on with development of the actual feature one way or > the other. I don't think it is a good tradeoff to have another set of encoders/decoders and an additional memory allocation / copy for IPC. So, I guess, r-.