Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Daniel Olegovich Lazarenko]

>> "Pure OOP style is always the right way"
Sorry, that's a typo, I meant "not always" of course. The examples clarify
that.

My point was that "release", "take" and "move" have well-established and
different meanings (with connotations that may or may not be logical
without the same background):
* release will free the memory if ref_count = 0 (Obj-C/CF on Mac/iOS)
* move just moves the ownership without freeing (C++)
* take removes and item from the collection and returns it (the ownership
is implicitly passed as well) (Java, C#, but not only). So map.take() means
that I still need that object most likely, and map.remove() means that :
feel free to throw the object to trash.
That are connotations I've seen in my practice.

On Tue, Sep 6, 2016 at 6:14 PM, Alfonso Guerra <hupernike...@gmail.com>
wrote:

>
>
> On Tue, Sep 6, 2016 at 4:29 AM, Daniel Olegovich Lazarenko <
> dani...@opera.com> wrote:
>
> ..
>
>
>> * "take" - a typical name for collections like a blocking queue, heap and
>> some others (usually ordered). If it's a collection's method, it's
>> logically expected to return an item. The key distinction between
>> fred.takeCandy() and say bowl.takeCandy() is that bowl is passive.
>>
>
> That doesn't make sense to me. Why would the object "bowl" be passive, but
> not "fred"?
>
> We treat bowl as a passive bag of data, and expect others to take from it.
>>
>
> I see. Like an actual bowl in the real world?
>
>
>> It's pretty easy to understand and remember, it makes intention more
>> clear than say "bowl.removeCandy()".
>>
>
> Not to me. When I read or write object-oriented code, I think of it as
> sending messages of what I want done to the object. I see the object as
> being an intermediator performing actions on behalf of the caller.
> Containers and collections are classes that group a set of functions the
> caller needs done, so it's more convenient to view them as being a
> mediator, if you will, for the caller.
>
> I think trying to map real-world behaviors into object interfaces is
> trying too hard to mirror the real world. I see it as imposing additional
> cognitive load on comprehension by requiring me to remember if it's passive
> or not. In fact, if it's passive that would violate the OOP and real-world
> paradigms: why would I be sending it a message?
>
> Especially in this day and age of smart appliances and IoT I think it's
> more consistent to think of the bowl as a "smart" bowl that responds to my
> messages. "Give me all the green candy", "sort candy by size", etc.
>
>
>> Pure OOP style is always the right way when it comes to readability. A
>> good example mentioned by Stroustrup once that it should be sqrt(5), not
>> 5.sqrt().
>>
>
> Do you have a link for that? The closest thing I see to that example (
> https://isocpp.org/blog/2014/12/myths-2) is demonstrating the exact
> opposite, that a non-OOP solution provides better performance by
> eliminating the dereferencing of a pointer.
>
>
>> Naming is fun.
>>
>
> Learning how to communicate across cultures of all types is fun. ;-)
>
>
> --
> Alfonso Guerra
> Founder/CEO
> Apokalypse Software Corp.
> (626) 667-4285
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Daniel Olegovich Lazarenko]

Hello,

For a WebKit observer like me:
* "release" - has a well-known meaning in Mac/Objective-C world. It's
expected to "free" the memory. Same as COM's IUnknown::Release, but
different from auto_ptr::release or unique_ptr::release (which don't free
the memory).
* "move" - has a well-known meaning in C++ 11 world. Different from
"release" above. If I see methods "move" and "release" and they do the
same, I will have to learn and understand that trick.
* "take" - a typical name for collections like a blocking queue, heap and
some others (usually ordered). If it's a collection's method, it's
logically expected to return an item. The key distinction between
fred.takeCandy() and say bowl.takeCandy() is that bowl is passive. We treat
bowl as a passive bag of data, and expect others to take from it. It's
pretty easy to understand and remember, it makes intention more clear than
say "bowl.removeCandy()".
Pure OOP style is always the right way when it comes to readability. A good
example mentioned by Stroustrup once that it should be sqrt(5), not
5.sqrt(). Maybe "bowl.takeCandy" is a good compromise to keep it as a
method (instead of a global "TakeCandyFromBowl(bowl)").

Naming is fun.

--
Daniel
https://twitter.com/battlmonstr

On Mon, Sep 5, 2016 at 9:00 PM,  wrote:

> Send webkit-dev mailing list submissions to
> webkit-dev@lists.webkit.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> or, via email, send a message with subject or body 'help' to
> webkit-dev-requ...@lists.webkit.org
>
> You can reach the person managing the list at
> webkit-dev-ow...@lists.webkit.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of webkit-dev digest..."
>
>
> Today's Topics:
>
>1. Terminology for giving up ownership: take, release,   move
>   (Darin Adler)
>2. Re: Terminology for giving up ownership: take, release, move
>   (Filip Pizlo)
>
>
> --
>
> Message: 1
> Date: Mon, 05 Sep 2016 10:13:28 -0700
> From: Darin Adler 
> To: WebKit Development Mailing List 
> Subject: [webkit-dev] Terminology for giving up ownership: take,
> release,move
> Message-ID: <3ad4bd53-7cc2-4f26-8d3d-b3631413b...@apple.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi folks.
>
> WebKit has some critical functions that involve asking an object to give
> up ownership of something so the caller can take ownership.
>
> In the C++ standard library itself, this is called move, as in std::move.
>
> In WebKit smart pointers, we call this operation release, as in
> RefPtr::releaseNonNull and String::releaseImpl.
>
> In WebKit collections, we call this operation take, as in HashMap::take
> and ExceptionOr::takeReturnValue.
>
> The release vs. take terminology is distracting to my eyes. The verb
> ?take" states what the caller wishes to do, and the verb ?release? states
> what the caller wants the collection or smart pointer to do. My first
> thought was be to rename the take functions to use the word release
> instead, but I fear it might make them harder to understand instead of
> easier and clearly it would make them longer.
>
> Does anyone have other ideas on how to collapse WebKit project terminology
> down so we don?t have three different single words that are used to mean
> almost the same thing?
>
> ? Darin
>
> --
>
> Message: 2
> Date: Mon, 05 Sep 2016 10:23:35 -0700
> From: Filip Pizlo 
> To: Darin Adler 
> Cc: WebKit Development 
> Subject: Re: [webkit-dev] Terminology for giving up ownership: take,
> release, move
> Message-ID: <8c068bfc-10d2-4388-919a-761ca9323...@apple.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > On Sep 5, 2016, at 10:13 AM, Darin Adler  wrote:
> >
> > Hi folks.
> >
> > WebKit has some critical functions that involve asking an object to give
> up ownership of something so the caller can take ownership.
> >
> > In the C++ standard library itself, this is called move, as in std::move.
> >
> > In WebKit smart pointers, we call this operation release, as in
> RefPtr::releaseNonNull and String::releaseImpl.
> >
> > In WebKit collections, we call this operation take, as in HashMap::take
> and ExceptionOr::takeReturnValue.
> >
> > The release vs. take terminology is distracting to my eyes. The verb
> ?take" states what the caller wishes to do, and the verb ?release? states
> what the caller wants the collection or smart pointer to do. My first
> thought was be to rename the take functions to use the word release
> instead, but I fear it might make them harder to understand instead of
> easier and clearly it would make them longer.
> >
> > Does anyone have other ideas on how 

Re: [webkit-dev] Networking proxy on iOS

[Daniel Olegovich Lazarenko]

There's another solution I'd like to point out.
The idea is to take the networking XPC service ID from NSUserDefaults.
That would technically make it possible to substitute the whole networking
process with a custom process.
The caveat here is that XPC is a private API on iOS, so it's not allowed to
do that.
On the other hand the good side about this solution is that the WebKit's
own networking process would still be separate and free from any app code,
so for example, the crash responsibility separation would still work, and
the WebKit team won't have to deal with any more testing configurations.

On Thu, May 19, 2016 at 5:41 PM, Daniel Olegovich Lazarenko <
dani...@opera.com> wrote:

> Hello,
>
> I'd like to ask your for advice about implementation of a custom
> networking layer with WKWebView on iOS.
>
> Our current solution is based on NSURLProtocol, and the issues we had with
> it in 2014 are unresolved:
> https://bugs.webkit.org/show_bug.cgi?id=137302
> https://bugs.webkit.org/show_bug.cgi?id=138131
>
> It was kind of a shoehorn hack, and so it was rejected by Benjamin Poulain
> and Alexey Proskuryakov among other reviewers.
>
> Now I'm again looking for a better solution.
> I'd really like to discuss it with somebody responsible, reach common
> understanding and agreement, and attack this problem.
>
> There's currently 2 solutions I'm weighting:
>
>1. Pass and use NetworkProcessCreationParameters.httpProxy to
>NSURLSessionConfiguration (in NetworkSession and maybe other places).
>2. Add a new mode to the NetworkProcess, which would do all networking
>in UIProcess (instead of spawning a new process). A mode would be optional
>and controlled with some configuration setting (or NSUserDefaults).
>
> The httpProxy solution is easy to implement and would look clean
> design-wise. It would let us spawn an HTTP proxy on localhost and filter
> the traffic there. There might be some complications, because it's not
> fully transparent to the client side. For example HTTPS will have issues.
> All in all this could be a fine short-term solution.
>
> The UIProcess solution is harder to implement, and it will affect more
> code. It is somewhat controversial. One of the reasons of splitting out a
> NetworkProcess was to have it respawn after crashes. Nevertheless we can
> take this risk, because in practice we know that most of the crashes happen
> in the WebProcess parts. I don't see any other significant downsides of
> having the UIProcess handling networking. To me this seems like a better
> choice than httpProxy, because this way we avoid unnecessary data passing
> back and forth. We get more control, because it's transparent. In addition
> it can simplify the NetworkProcess debugging.
>
> --
> With best regards,
> Daniel Lazarenko
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Networking proxy on iOS

[Daniel Olegovich Lazarenko]

Hello Sam,

Nice to hear from you again.

We have outlined our use cases a year ago here:
https://bugs.webkit.org/show_bug.cgi?id=137299
The use cases were collected from Opera's browser products, Chrome and
Yandex people were participating as well.

That patch solution was blocked back then, but all the use cases stayed. My
intention was to rework the solution to be suitable for Apple. I completely
understand that you want to control the architecture with a
kungFuDeathGrip, but at the same time have other priorities, and just have
limited time devotion. That's why I proposed to collaborate on a spec,
which shouldn't take too much of your time.

I see that now a new use case discussion is rolling out in
https://bugs.webkit.org/show_bug.cgi?id=138169
The comment from Stefan (a Firefox developer) really resonated to us in
terms of use cases.
We actually have some more to add. I'm going to make an updated list of use
cases and comment on the bug there.


On Mon, May 23, 2016 at 10:00 PM, Sam Weinig <wei...@apple.com> wrote:

>
> On May 22, 2016, at 3:39 PM, Daniel Olegovich Lazarenko <dani...@opera.com>
> wrote:
>
> What if I make a bug report in bugzilla about making a design spec of this
> feature. I could then write down implementation details options and
> summarize all points we've discussed here. Maybe in a form of a google
> document. This spec could then be reviewed and approved for action by you
> and any other interested people you want to be involved. Do you think it
> could work better?
>
>
> Before getting to the design of things, we usually spend quite a bit of
> time figuring out what the use cases are, and from the those use cases,
> what the different possible solutions are that address those use cases.  I
> don’t feel we have gotten past the use case part yet.
>
> - Sam
>
>
> On Sun, May 22, 2016 at 11:59 PM, Brady Eidson <beid...@apple.com> wrote:
>
>>
>> On May 22, 2016, at 3:14 AM, Daniel Olegovich Lazarenko <
>> dani...@opera.com> wrote:
>>
>> > It’s not yet clear what the ideal architecture is, which is one of the
>> reasons why the mentioned issued remains unresolved.
>>
>> What are the other reasons?
>>
>>
>> Perhaps I misrepresented - AFAIK that is the only important reason.
>>
>> Are there any reasons that block us from discussing the right
>> architecture?
>> I'd like to start working on a patch, but I need directions from you.
>>
>>
>> I replied to this thread to describe significant issues with the two
>> approaches you suggested.
>>
>> But I am not able to conclude the thread by unilaterally giving
>> directions to a lone contributor on how to properly implement this feature.
>>
>> That’s a much broader conversation than just you and I.
>>
>> Thanks,
>> ~Brady
>>
>>
>> I'd like to come up with some sort of a plan for this as well. Since the
>> desired approach sounds complicated, it would be nice to split it as a
>> series of patches where each patch is committed separately and improves the
>> feature towards the goal.
>>
>> On Sun, May 22, 2016 at 6:16 AM, Brady Eidson <beid...@apple.com> wrote:
>>
>>>
>>> On May 21, 2016, at 2:05 PM, Daniel Olegovich Lazarenko <
>>> dani...@opera.com> wrote:
>>>
>>> > We are exploring ways to restore that full functionality -
>>> https://bugs.webkit.org/show_bug.cgi?id=138169
>>>
>>> Having custom scheme protocols is important to me too. I didn't know
>>> that it is broken with WKWebView. Do you know what exactly is broken?
>>>
>>>
>>> From most developer’s perspective, what is broken is that their
>>> NSURLProtocol they can register in their “UI Process” that used to work in
>>> WK1 views no longer has any effect in WK2.
>>>
>>>
>>> I thought that if you call [WKBrowsingContextController
>>> registerSchemeForCustomProtocol:] with your scheme, then it works. When I
>>> checked last (a year ago) it was implemented in a way that the WebProcess/
>>> NetworkingProcess would pass a message to UIProcess, and handle the
>>> network request in the UIProcess. Did it change?
>>>
>>>
>>> That did not change.
>>>
>>> But that mechanism was never API, and even as SPI it is formally
>>> deprecated.
>>>
>>> Assuming that registerSchemeForCustomProtocol still works the same way,
>>> you basically state that you dislike the current solution (that does the
>>> work in the UIProcess), and want to have a different architecture.
>>>
>>> For

Re: [webkit-dev] Networking proxy on iOS

[Daniel Olegovich Lazarenko]

What if I make a bug report in bugzilla about making a design spec of this
feature. I could then write down implementation details options and
summarize all points we've discussed here. Maybe in a form of a google
document. This spec could then be reviewed and approved for action by you
and any other interested people you want to be involved. Do you think it
could work better?

On Sun, May 22, 2016 at 11:59 PM, Brady Eidson <beid...@apple.com> wrote:

>
> On May 22, 2016, at 3:14 AM, Daniel Olegovich Lazarenko <dani...@opera.com>
> wrote:
>
> > It’s not yet clear what the ideal architecture is, which is one of the
> reasons why the mentioned issued remains unresolved.
>
> What are the other reasons?
>
>
> Perhaps I misrepresented - AFAIK that is the only important reason.
>
> Are there any reasons that block us from discussing the right architecture?
> I'd like to start working on a patch, but I need directions from you.
>
>
> I replied to this thread to describe significant issues with the two
> approaches you suggested.
>
> But I am not able to conclude the thread by unilaterally giving directions
> to a lone contributor on how to properly implement this feature.
>
> That’s a much broader conversation than just you and I.
>
> Thanks,
> ~Brady
>
>
> I'd like to come up with some sort of a plan for this as well. Since the
> desired approach sounds complicated, it would be nice to split it as a
> series of patches where each patch is committed separately and improves the
> feature towards the goal.
>
> On Sun, May 22, 2016 at 6:16 AM, Brady Eidson <beid...@apple.com> wrote:
>
>>
>> On May 21, 2016, at 2:05 PM, Daniel Olegovich Lazarenko <
>> dani...@opera.com> wrote:
>>
>> > We are exploring ways to restore that full functionality -
>> https://bugs.webkit.org/show_bug.cgi?id=138169
>>
>> Having custom scheme protocols is important to me too. I didn't know that
>> it is broken with WKWebView. Do you know what exactly is broken?
>>
>>
>> From most developer’s perspective, what is broken is that their
>> NSURLProtocol they can register in their “UI Process” that used to work in
>> WK1 views no longer has any effect in WK2.
>>
>>
>> I thought that if you call [WKBrowsingContextController
>> registerSchemeForCustomProtocol:] with your scheme, then it works. When I
>> checked last (a year ago) it was implemented in a way that the WebProcess/
>> NetworkingProcess would pass a message to UIProcess, and handle the
>> network request in the UIProcess. Did it change?
>>
>>
>> That did not change.
>>
>> But that mechanism was never API, and even as SPI it is formally
>> deprecated.
>>
>> Assuming that registerSchemeForCustomProtocol still works the same way,
>> you basically state that you dislike the current solution (that does the
>> work in the UIProcess), and want to have a different architecture.
>>
>> For custom networking or proxying you have to run the app-provided code.
>> The basic strategy I proposed was to run it in the app process (i.e.
>> UIProcess). Since you don't want any networking in UIProcess, it means that
>> the app needs to spawn a dedicated process to do custom networking. This
>> process would run app-specific code (including NSURLProtocol-s), and
>> communicate by IPC with the NetworkingProcess. Is this a kind of
>> architecture you would like to have?
>>
>>
>> It’s not yet clear what the ideal architecture is, which is one of the
>> reasons why the mentioned issued remains unresolved.
>>
>> Thanks,
>> ~Brady
>>
>>
>>
>>
>> On Fri, May 20, 2016 at 5:58 PM, Brady Eidson <beid...@apple.com> wrote:
>>
>>>
>>> On May 20, 2016, at 2:30 AM, Daniel Olegovich Lazarenko <
>>> dani...@opera.com> wrote:
>>>
>>> Thank you for such a fast reply. That is amazing! :)
>>> Back to questions...
>>>
>>> > Are you primarily focused on a custom networking layer (e.g. your own
>>> HTTP implementation?),
>>> > or with custom protocol handling for non-http protocols?
>>>
>>> I'm primarily concerned about HTTP and friends (HTTPS, SPDY, HTTP2), but
>>> if there are any other widely used protocols that's also interesting. FTP
>>> support is not interesting for me. Do you have any other specific things in
>>> mind?
>>>
>>> If there's a custom proprietary protocol that people handle in the app
>>> with their own code, for example, acme://acme.com:1234, then proxying
>>> this thing is not ve

Re: [webkit-dev] Networking proxy on iOS

[Daniel Olegovich Lazarenko]

> It’s not yet clear what the ideal architecture is, which is one of the
reasons why the mentioned issued remains unresolved.

What are the other reasons?
Are there any reasons that block us from discussing the right architecture?
I'd like to start working on a patch, but I need directions from you.

I'd like to come up with some sort of a plan for this as well. Since the
desired approach sounds complicated, it would be nice to split it as a
series of patches where each patch is committed separately and improves the
feature towards the goal.

On Sun, May 22, 2016 at 6:16 AM, Brady Eidson <beid...@apple.com> wrote:

>
> On May 21, 2016, at 2:05 PM, Daniel Olegovich Lazarenko <dani...@opera.com>
> wrote:
>
> > We are exploring ways to restore that full functionality -
> https://bugs.webkit.org/show_bug.cgi?id=138169
>
> Having custom scheme protocols is important to me too. I didn't know that
> it is broken with WKWebView. Do you know what exactly is broken?
>
>
> From most developer’s perspective, what is broken is that their
> NSURLProtocol they can register in their “UI Process” that used to work in
> WK1 views no longer has any effect in WK2.
>
>
> I thought that if you call [WKBrowsingContextController
> registerSchemeForCustomProtocol:] with your scheme, then it works. When I
> checked last (a year ago) it was implemented in a way that the WebProcess/
> NetworkingProcess would pass a message to UIProcess, and handle the
> network request in the UIProcess. Did it change?
>
>
> That did not change.
>
> But that mechanism was never API, and even as SPI it is formally
> deprecated.
>
> Assuming that registerSchemeForCustomProtocol still works the same way,
> you basically state that you dislike the current solution (that does the
> work in the UIProcess), and want to have a different architecture.
>
> For custom networking or proxying you have to run the app-provided code.
> The basic strategy I proposed was to run it in the app process (i.e.
> UIProcess). Since you don't want any networking in UIProcess, it means that
> the app needs to spawn a dedicated process to do custom networking. This
> process would run app-specific code (including NSURLProtocol-s), and
> communicate by IPC with the NetworkingProcess. Is this a kind of
> architecture you would like to have?
>
>
> It’s not yet clear what the ideal architecture is, which is one of the
> reasons why the mentioned issued remains unresolved.
>
> Thanks,
> ~Brady
>
>
>
>
> On Fri, May 20, 2016 at 5:58 PM, Brady Eidson <beid...@apple.com> wrote:
>
>>
>> On May 20, 2016, at 2:30 AM, Daniel Olegovich Lazarenko <
>> dani...@opera.com> wrote:
>>
>> Thank you for such a fast reply. That is amazing! :)
>> Back to questions...
>>
>> > Are you primarily focused on a custom networking layer (e.g. your own
>> HTTP implementation?),
>> > or with custom protocol handling for non-http protocols?
>>
>> I'm primarily concerned about HTTP and friends (HTTPS, SPDY, HTTP2), but
>> if there are any other widely used protocols that's also interesting. FTP
>> support is not interesting for me. Do you have any other specific things in
>> mind?
>>
>> If there's a custom proprietary protocol that people handle in the app
>> with their own code, for example, acme://acme.com:1234, then proxying
>> this thing is not very interesting to me, because it's very easy to proxy
>> my own protocol handled by my own code. There's a case when "acme" is
>> provided by some 3rd party, and the app author doesn't have the processing
>> code. In such case it might be interesting to proxy it as well, but then
>> again, I'm asking for a concrete example of such protocol (in WebKit
>> context).
>>
>>
>> In a WebKit1 app (WebView on Mac, UIWebView on iOS), app authors were
>> able to use NSURLProtocol to override any scheme they wished.
>>
>> While some such as yourself might’ve used it to override http from the
>> default handling, *many more* used it to implement custom protocols. e.g. “
>> acme://my-app-specific-url”
>>
>> We are exploring ways to restore that full functionality -
>> https://bugs.webkit.org/show_bug.cgi?id=138169
>>
>> > You seem to dismiss the Networking process’ crash recovery aspect.
>> > "because in practice we know that most of the crashes happen in the
>> WebProcess parts”.
>> > I’m curious what data you’re using to make that claim?
>>
>> Well, I'm not dismissing it, it's definitely a trade off that an app
>> author will make by choosing to enable this option.
>> The data comes from our web brows

Re: [webkit-dev] Networking proxy on iOS

[Daniel Olegovich Lazarenko]

> We are exploring ways to restore that full functionality -
https://bugs.webkit.org/show_bug.cgi?id=138169

Having custom scheme protocols is important to me too. I didn't know that
it is broken with WKWebView. Do you know what exactly is broken?

I thought that if you call [WKBrowsingContextController
registerSchemeForCustomProtocol:] with your scheme, then it works. When I
checked last (a year ago) it was implemented in a way that the WebProcess/
NetworkingProcess would pass a message to UIProcess, and handle the network
request in the UIProcess. Did it change?

Assuming that registerSchemeForCustomProtocol still works the same way, you
basically state that you dislike the current solution (that does the work
in the UIProcess), and want to have a different architecture.

For custom networking or proxying you have to run the app-provided code.
The basic strategy I proposed was to run it in the app process (i.e.
UIProcess). Since you don't want any networking in UIProcess, it means that
the app needs to spawn a dedicated process to do custom networking. This
process would run app-specific code (including NSURLProtocol-s), and
communicate by IPC with the NetworkingProcess. Is this a kind of
architecture you would like to have?

Please don't get me wrong, I'm just trying to clarify that I understand you
correctly.

> Adding this “optional” networking mode would double certain testing
matrices
> and make development in this area (which there has been a lot of lately)
more difficult.

I totally believe that.
I hope that we eventually come to a solution that works well for you, and
that you could potentially approve and commit.



On Fri, May 20, 2016 at 5:58 PM, Brady Eidson <beid...@apple.com> wrote:

>
> On May 20, 2016, at 2:30 AM, Daniel Olegovich Lazarenko <dani...@opera.com>
> wrote:
>
> Thank you for such a fast reply. That is amazing! :)
> Back to questions...
>
> > Are you primarily focused on a custom networking layer (e.g. your own
> HTTP implementation?),
> > or with custom protocol handling for non-http protocols?
>
> I'm primarily concerned about HTTP and friends (HTTPS, SPDY, HTTP2), but
> if there are any other widely used protocols that's also interesting. FTP
> support is not interesting for me. Do you have any other specific things in
> mind?
>
> If there's a custom proprietary protocol that people handle in the app
> with their own code, for example, acme://acme.com:1234, then proxying
> this thing is not very interesting to me, because it's very easy to proxy
> my own protocol handled by my own code. There's a case when "acme" is
> provided by some 3rd party, and the app author doesn't have the processing
> code. In such case it might be interesting to proxy it as well, but then
> again, I'm asking for a concrete example of such protocol (in WebKit
> context).
>
>
> In a WebKit1 app (WebView on Mac, UIWebView on iOS), app authors were able
> to use NSURLProtocol to override any scheme they wished.
>
> While some such as yourself might’ve used it to override http from the
> default handling, *many more* used it to implement custom protocols. e.g. “
> acme://my-app-specific-url”
>
> We are exploring ways to restore that full functionality -
> https://bugs.webkit.org/show_bug.cgi?id=138169
>
> > You seem to dismiss the Networking process’ crash recovery aspect.
> > "because in practice we know that most of the crashes happen in the
> WebProcess parts”.
> > I’m curious what data you’re using to make that claim?
>
> Well, I'm not dismissing it, it's definitely a trade off that an app
> author will make by choosing to enable this option.
> The data comes from our web browser apps. We certainly see networking
> faults, but in total it was usually a minor part of all the WebKit crashes.
> To not sound subjective, I've looked through our current app version, which
> already has enough data to judge, and in the top WebKit crashes there are
> none in the network code. Most are crashes in JavaScriptCore, DOM and
> graphics subsystems. This is the experience we have over many versions and
> years of service. I might be able to show you the data in private if you
> want, although I'm sure that you have your own crash analysis system with
> much more data.
>
>
> Without getting in to specifics, the NetworkingProcess does crash.
>
> And while the WebContent process does crash way more, it usually only
> effects that one web page.
>
> If networking code was back inside the UI Process, and it crashed, that
> takes down the whole browser.
>
> Doing so would be reverting towards the single process architecture of
> yesteryear, not progressing away from it.
>
> Let's discuss the sandboxing a little bit. First of all, and correct me if
> I'm wrong

Re: [webkit-dev] Networking proxy on iOS

[Daniel Olegovich Lazarenko]

Thank you for such a fast reply. That is amazing! :)
Back to questions...

> Are you primarily focused on a custom networking layer (e.g. your own
HTTP implementation?),
> or with custom protocol handling for non-http protocols?

I'm primarily concerned about HTTP and friends (HTTPS, SPDY, HTTP2), but if
there are any other widely used protocols that's also interesting. FTP
support is not interesting for me. Do you have any other specific things in
mind?

If there's a custom proprietary protocol that people handle in the app with
their own code, for example, acme://acme.com:1234, then proxying this thing
is not very interesting to me, because it's very easy to proxy my own
protocol handled by my own code. There's a case when "acme" is provided by
some 3rd party, and the app author doesn't have the processing code. In
such case it might be interesting to proxy it as well, but then again, I'm
asking for a concrete example of such protocol (in WebKit context).

> I’m not sure it’s useful for WebKit to spend energy testing and
maintaining a mechanism
> that *only* allows for HTTP-handling replacement and doesn’t also allow
for
> the oft-requested feature of custom protocol handling.

I understand your concerns. Let's say that we forget the httpProxy solution
for now, and discuss the 2nd UIProcess-networking approach a bit more.

> You seem to dismiss the Networking process’ crash recovery aspect.
> "because in practice we know that most of the crashes happen in the
WebProcess parts”.
> I’m curious what data you’re using to make that claim?

Well, I'm not dismissing it, it's definitely a trade off that an app author
will make by choosing to enable this option.
The data comes from our web browser apps. We certainly see networking
faults, but in total it was usually a minor part of all the WebKit crashes.
To not sound subjective, I've looked through our current app version, which
already has enough data to judge, and in the top WebKit crashes there are
none in the network code. Most are crashes in JavaScriptCore, DOM and
graphics subsystems. This is the experience we have over many versions and
years of service. I might be able to show you the data in private if you
want, although I'm sure that you have your own crash analysis system with
much more data.

> The Networking process provides significant benefit unrelated to crash
recovery
> that should not be abandoned for convenience sake. e.g. Sandboxing.
> Especially when moving the networking to the UI process
> would also end up moving 3rd party code execution into the UI process,
> this seems like an unacceptable regression.

Let's discuss the sandboxing a little bit. First of all, and correct me if
I'm wrong: I thought that there's no 3rd party code execution in the
networking process, and all the JS execution happens inside the WebProcess.
The code that we want to run is our own code that we control that we
implement in a safe and secure manner. In this sense it's no less secure.
In the end we are always protected by the iOS/Mac sandbox. Maybe I'm wrong
about JS here, or do you have some other use case in mind?

> Debugging the multi process architecture of WebKit2
> has not gotten any harder in years, active developers have all adapted,
> and new developers tend to pick it up pretty quickly. This is not a
useful point.

I'm sorry that you are rejecting this. Of course you can adapt to that, but
it inevitably has a steeper learning curve, and takes longer time. Many app
developers come from a single-process background and find multi-process
debugging much harder. Often it's a real challenge to understand what's
going on. I'm sure that you in your team have multiple stories that show
how non-trivial it is, and tricks about dealing with it. Nevertheless, I
agree, it's not a decisive point.



On Thu, May 19, 2016 at 6:43 PM, Brady Eidson <beid...@apple.com> wrote:

>
> On May 19, 2016, at 8:41 AM, Daniel Olegovich Lazarenko <dani...@opera.com>
> wrote:
>
> I'd like to ask your for advice about implementation of a custom
> networking layer
>
>
> Are you primarily focused on a custom networking layer (e.g. your own HTTP
> implementation?), or with custom protocol handling for non-http protocols?
>
> ...with WKWebView on iOS.
>
>
> WKWebView is an API that ships on both OS X and iOS. When a design aspect
> of it affects both platforms (such as the networking behavior), we must
> consider both platforms.
>
> Our current solution is based on NSURLProtocol, and the issues we had with
> it in 2014 are unresolved:
> https://bugs.webkit.org/show_bug.cgi?id=137302
> https://bugs.webkit.org/show_bug.cgi?id=138131
>
> It was kind of a shoehorn hack, and so it was rejected by Benjamin Poulain
> and Alexey Proskuryakov among other reviewers.
>
>
> I’m not sure it’s useful for WebKit to spend energy testing and

[webkit-dev] Networking proxy on iOS

[Daniel Olegovich Lazarenko]

Hello,

I'd like to ask your for advice about implementation of a custom networking
layer with WKWebView on iOS.

Our current solution is based on NSURLProtocol, and the issues we had with
it in 2014 are unresolved:
https://bugs.webkit.org/show_bug.cgi?id=137302
https://bugs.webkit.org/show_bug.cgi?id=138131

It was kind of a shoehorn hack, and so it was rejected by Benjamin Poulain
and Alexey Proskuryakov among other reviewers.

Now I'm again looking for a better solution.
I'd really like to discuss it with somebody responsible, reach common
understanding and agreement, and attack this problem.

There's currently 2 solutions I'm weighting:

   1. Pass and use NetworkProcessCreationParameters.httpProxy to
   NSURLSessionConfiguration (in NetworkSession and maybe other places).
   2. Add a new mode to the NetworkProcess, which would do all networking
   in UIProcess (instead of spawning a new process). A mode would be optional
   and controlled with some configuration setting (or NSUserDefaults).

The httpProxy solution is easy to implement and would look clean
design-wise. It would let us spawn an HTTP proxy on localhost and filter
the traffic there. There might be some complications, because it's not
fully transparent to the client side. For example HTTPS will have issues.
All in all this could be a fine short-term solution.

The UIProcess solution is harder to implement, and it will affect more
code. It is somewhat controversial. One of the reasons of splitting out a
NetworkProcess was to have it respawn after crashes. Nevertheless we can
take this risk, because in practice we know that most of the crashes happen
in the WebProcess parts. I don't see any other significant downsides of
having the UIProcess handling networking. To me this seems like a better
choice than httpProxy, because this way we avoid unnecessary data passing
back and forth. We get more control, because it's transparent. In addition
it can simplify the NetworkProcess debugging.

--
With best regards,
Daniel Lazarenko
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev