Move the Extension Port implementation out of messaging.js into its own file port.js.

Move the Extension Port implementation out of messaging.js into its own file port.js.

messaging.js is too large to handle right now.

R=rdevlin.cronin@chromium.org
BUG=475536
Committed: https://crrev.com/32b3a84be9aa4f70e83bd47c2a5cb32f05ad7f7e
Cr-Commit-Position: refs/heads/master@{#325585}

[not at google - send to devlin, 2015-04-16 23:36:19]

Pretty simple. I renamed PortImpl to Port as part of this change. PortImpl
bugged me (and it was my fault for calling it that in the first place). Next
will be pulling Port management into its own file, which will be more
complicated.

[Devlin, 2015-04-17 00:14:52]

https://codereview.chromium.org/1097583004/diff/1/extensions/renderer/resourc...
File extensions/renderer/resources/messaging.js (right):

https://codereview.chromium.org/1097583004/diff/1/extensions/renderer/resourc...
extensions/renderer/resources/messaging.js:308: privates(port).impl.onDestroy_ =
function() {
I don't love this part, especially now that it's in its own file.  How opposed
would you be to making a generic port.onDestroyedListener, that can be called
from port itself?

[not at google - send to devlin, 2015-04-17 00:16:34]

https://codereview.chromium.org/1097583004/diff/1/extensions/renderer/resourc...
File extensions/renderer/resources/messaging.js (right):

https://codereview.chromium.org/1097583004/diff/1/extensions/renderer/resourc...
extensions/renderer/resources/messaging.js:308: privates(port).impl.onDestroy_ =
function() {
On 2015/04/17 00:14:52, Devlin wrote:
> I don't love this part, especially now that it's in its own file.  How opposed
> would you be to making a generic port.onDestroyedListener, that can be called
> from port itself?

You need to be careful, because Ports are exposed directly to extensions and we
don't want to give those an onDestroyedListener.

When I create port manager this should go away.

[Devlin, 2015-04-17 00:25:53]

Assuming this is a temporary fix until implemented in C++, lgtm with or without
the onDestroyedListener.

https://codereview.chromium.org/1097583004/diff/1/extensions/renderer/resourc...
File extensions/renderer/resources/messaging.js (right):

https://codereview.chromium.org/1097583004/diff/1/extensions/renderer/resourc...
extensions/renderer/resources/messaging.js:308: privates(port).impl.onDestroy_ =
function() {
On 2015/04/17 00:16:34, kalman wrote:
> On 2015/04/17 00:14:52, Devlin wrote:
> > I don't love this part, especially now that it's in its own file.  How
opposed
> > would you be to making a generic port.onDestroyedListener, that can be
called
> > from port itself?
> 
> You need to be careful, because Ports are exposed directly to extensions and
we
> don't want to give those an onDestroyedListener.
> 
> When I create port manager this should go away.

Right, in my mind there's:
Private private: Nothing but the class itself
Public private: Accessible through privates()
Public public: Accessible via extensions

Right now, this strikes me as the first - I was suggesting make it the second.

[not at google - send to devlin, 2015-04-17 00:27:59]

https://codereview.chromium.org/1097583004/diff/1/extensions/renderer/resourc...
File extensions/renderer/resources/messaging.js (right):

https://codereview.chromium.org/1097583004/diff/1/extensions/renderer/resourc...
extensions/renderer/resources/messaging.js:308: privates(port).impl.onDestroy_ =
function() {
On 2015/04/17 00:25:52, Devlin wrote:
> On 2015/04/17 00:16:34, kalman wrote:
> > On 2015/04/17 00:14:52, Devlin wrote:
> > > I don't love this part, especially now that it's in its own file.  How
> opposed
> > > would you be to making a generic port.onDestroyedListener, that can be
> called
> > > from port itself?
> > 
> > You need to be careful, because Ports are exposed directly to extensions and
> we
> > don't want to give those an onDestroyedListener.
> > 
> > When I create port manager this should go away.
> 
> Right, in my mind there's:
> Private private: Nothing but the class itself
> Public private: Accessible through privates()
> Public public: Accessible via extensions
> 
> Right now, this strikes me as the first - I was suggesting make it the second.

Heh, a distinction unique to these JS bindings.

Another design I had considered was to make some kind of InternalPort class
which handled the real Port to give to the extension. However, such an
InternalPort would belong inside the port manager, so if that's the design that
makes the most sense - that's what it will end up as.

[not at google - send to devlin, 2015-04-17 00:29:11]

The CQ bit was checked by kalman@chromium.org

[commit-bot: I haz the power, 2015-04-17 00:30:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1097583004/1

[commit-bot: I haz the power, 2015-04-17 02:02:49]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-04-17 02:04:02]

Patchset 1 (id:??) landed as
https://crrev.com/32b3a84be9aa4f70e83bd47c2a5cb32f05ad7f7e
Cr-Commit-Position: refs/heads/master@{#325585}