Break out balsa and epoll_server from net/tools/flip_server.

Break out balsa and epoll_server from net/tools/flip_server.

balsa is an HTTP headers/framing abstraction used by code in net/tools/flip_server and net/tools/quic.

epoll_server is a event-driven server abstraction based on (as the name suggested) epoll.  It is also used by code in net/tools/flip_server and net/tools/quic.

Since these are both shared across different layers, it makes sense to split them into different directories.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=225890

[Ryan Sleevi, 2013-09-27 19:39:21]

Can you please update the comment description to actually include the details we
discussed over chat?

Namely, what balsa and epoll_server contains, and why it makes sense to split
this off from flip.

https://codereview.chromium.org/25085002/diff/6001/net/net.gyp
File net/net.gyp (right):

https://codereview.chromium.org/25085002/diff/6001/net/net.gyp#newcode1906
net/net.gyp:1906: 'balsa_library',
Editorial question: Why the suffix "_library"? Most of Chromium's GYP files
don't make this distinction here.

Same applies for "quic_library", in that sense.

Are these truly meant to be standalone (eg: no dependents on Chromium at all?)
Would we be better moving them to a third_party style directory, the same way
that we do other Google-internally-developed-but-opensourced-libraries?

[Ryan Sleevi, 2013-09-27 19:39:26]

lgtm

[Ryan Hamilton, 2013-09-27 19:55:35]

https://codereview.chromium.org/25085002/diff/6001/net/net.gyp
File net/net.gyp (right):

https://codereview.chromium.org/25085002/diff/6001/net/net.gyp#newcode1906
net/net.gyp:1906: 'balsa_library',
On 2013/09/27 19:39:21, Ryan Sleevi wrote:
> Editorial question: Why the suffix "_library"? Most of Chromium's GYP files
> don't make this distinction here.
> 
> Same applies for "quic_library", in that sense.
> 

Hm.  I'll give you the history first, and then we can see if we can figure out
better names.  So in flip_server, we have/had:

* the "core" flip code - in the flip_server__library target
* the actual flip_server binary - in the flip_server target
* the tests - in a flip_server_test target

net/tools/quic was similar.  We had core, tests, and client/server.  At some
point, we realized that the tests were not being run from the tree and decided
to fold them into net_unittests.  This is unmitigated goodness, as far as I can
tell :>

I'd be happy to use a different naming convention.  For the binaries we could
use
quic_client, quic_server, flip_server (well, really _in_mem_edsm_, but
whatever).  Cool?

But what would you suggest for the core? quic_support/flip_support? _tools? 
something else?

Happy to rename balsa_library to "balsa" and "epoll_server_library" to
"epoll_server" if you prefer?

> Are these truly meant to be standalone (eg: no dependents on Chromium at all?)
> Would we be better moving them to a third_party style directory, the same way
> that we do other Google-internally-developed-but-opensourced-libraries?

flip and quic are definitely not intended to be standalone.  balsa and epoll are
not intended to be supported for use by third parties, though they don't have
any direct dependencies on chromium.

[Ryan Sleevi, 2013-09-27 23:50:38]

On 2013/09/27 19:55:35, Ryan Hamilton wrote:
> https://codereview.chromium.org/25085002/diff/6001/net/net.gyp
> File net/net.gyp (right):
> 
> https://codereview.chromium.org/25085002/diff/6001/net/net.gyp#newcode1906
> net/net.gyp:1906: 'balsa_library',
> On 2013/09/27 19:39:21, Ryan Sleevi wrote:
> > Editorial question: Why the suffix "_library"? Most of Chromium's GYP files
> > don't make this distinction here.
> > 
> > Same applies for "quic_library", in that sense.
> > 
> 
> Hm.  I'll give you the history first, and then we can see if we can figure out
> better names.  So in flip_server, we have/had:
> 
> * the "core" flip code - in the flip_server__library target
> * the actual flip_server binary - in the flip_server target
> * the tests - in a flip_server_test target
> 
> net/tools/quic was similar.  We had core, tests, and client/server.  At some
> point, we realized that the tests were not being run from the tree and decided
> to fold them into net_unittests.  This is unmitigated goodness, as far as I
can
> tell :>
> 
> I'd be happy to use a different naming convention.  For the binaries we could
> use
> quic_client, quic_server, flip_server (well, really _in_mem_edsm_, but
> whatever).  Cool?
> 
> But what would you suggest for the core? quic_support/flip_support? _tools? 
> something else?

quic_core ? Doesn't seem like it's "support" if it's the core. We've done this
for things like PPAPI and autofill.

Alternatively, base (eg: remoting_base)

> 
> Happy to rename balsa_library to "balsa" and "epoll_server_library" to
> "epoll_server" if you prefer?

Both names SGTM.

> 
> > Are these truly meant to be standalone (eg: no dependents on Chromium at
all?)
> > Would we be better moving them to a third_party style directory, the same
way
> > that we do other Google-internally-developed-but-opensourced-libraries?
> 
> flip and quic are definitely not intended to be standalone.  balsa and epoll
are
> not intended to be supported for use by third parties, though they don't have
> any direct dependencies on chromium.

We should consider moving out balsa and epoll into a third_party library then,
especially if they're meant to (continually) mirror internal changes. We can
then add a note so that we don't introduce code drift and can easily merge in
changes.

[Ryan Hamilton, 2013-09-28 14:10:45]

On 2013/09/27 23:50:38, Ryan Sleevi wrote:
> On 2013/09/27 19:55:35, Ryan Hamilton wrote:
> > https://codereview.chromium.org/25085002/diff/6001/net/net.gyp
> > File net/net.gyp (right):
> > 
> > https://codereview.chromium.org/25085002/diff/6001/net/net.gyp#newcode1906
> > net/net.gyp:1906: 'balsa_library',
> > On 2013/09/27 19:39:21, Ryan Sleevi wrote:
> > > Editorial question: Why the suffix "_library"? Most of Chromium's GYP
files
> > > don't make this distinction here.
> > > 
> > > Same applies for "quic_library", in that sense.
> > > 
> > 
> > Hm.  I'll give you the history first, and then we can see if we can figure
out
> > better names.  So in flip_server, we have/had:
> > 
> > * the "core" flip code - in the flip_server__library target
> > * the actual flip_server binary - in the flip_server target
> > * the tests - in a flip_server_test target
> > 
> > net/tools/quic was similar.  We had core, tests, and client/server.  At some
> > point, we realized that the tests were not being run from the tree and
decided
> > to fold them into net_unittests.  This is unmitigated goodness, as far as I
> can
> > tell :>
> > 
> > I'd be happy to use a different naming convention.  For the binaries we
could
> > use
> > quic_client, quic_server, flip_server (well, really _in_mem_edsm_, but
> > whatever).  Cool?
> > 
> > But what would you suggest for the core? quic_support/flip_support? _tools? 
> > something else?
> 
> quic_core ? Doesn't seem like it's "support" if it's the core. We've done this
> for things like PPAPI and autofill.
> 
> Alternatively, base (eg: remoting_base)

Done!

> 
> > 
> > Happy to rename balsa_library to "balsa" and "epoll_server_library" to
> > "epoll_server" if you prefer?
> 
> Both names SGTM.

Done.

> > 
> > > Are these truly meant to be standalone (eg: no dependents on Chromium at
> all?)
> > > Would we be better moving them to a third_party style directory, the same
> way
> > > that we do other Google-internally-developed-but-opensourced-libraries?
> > 
> > flip and quic are definitely not intended to be standalone.  balsa and epoll
> are
> > not intended to be supported for use by third parties, though they don't
have
> > any direct dependencies on chromium.
> 
> We should consider moving out balsa and epoll into a third_party library then,
> especially if they're meant to (continually) mirror internal changes. We can
> then add a note so that we don't introduce code drift and can easily merge in
> changes.

SGTM.

[commit-bot: I haz the power, 2013-09-28 14:10:59]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rch@chromium.org/25085002/14001

[commit-bot: I haz the power, 2013-09-28 14:25:06]

Sorry for I got bad news for ya.
Compile failed with a clobber build on linux_chromeos_clang.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2013-09-28 15:42:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rch@chromium.org/25085002/7076

[commit-bot: I haz the power, 2013-09-28 17:03:25]

Retried try job too often on linux_rel for step(s) base_unittests,
browser_tests, interactive_ui_tests, net_unittests, unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...

[commit-bot: I haz the power, 2013-09-28 21:04:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rch@chromium.org/25085002/56001

[commit-bot: I haz the power, 2013-09-29 00:00:20]

Retried try job too often on linux_chromeos for step(s) unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[commit-bot: I haz the power, 2013-09-29 02:59:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rch@chromium.org/25085002/56001

[commit-bot: I haz the power, 2013-09-29 12:02:38]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rch@chromium.org/25085002/56001

[commit-bot: I haz the power, 2013-09-29 15:27:53]

Change committed as 225890