9f8cbc3462
* BlimpConnection is now an abstract class. * TCPConnection and tests are moved out of BlimpConnection. * BlimpConnection no longer knows about TCP-related classes including MessagePort and such. * Also in this CL: Skeleton gRPC plugin points. * Fixed all unit-tests. The overall idea is to enable gRPC support in Blimp. This is the first of a few CLs. In this CL I tease apart the existing BlimpConnection and BlimpTransport into the specific TCPConnection and TCP*Transport classes. Next, I will introduce GrpcConnection and GrpcTransport that will use allow passing of BlimpMessages through Grpc layer. However, internally, GrpcConnection and GrpcTransport will use the new GrpcStream which implements the checked in HeliumStream interface. Once this settles, the BlimpConnection and BlimpTransport-related classes (specifically, TCP/SSL/etc classes) will be removed and only the Helium-based transport mechanism will be used. Initially though the Helium protocol settles, this will first involve removing the TCP* classes alone. Review-Url: https://codereview.chromium.org/2439403003 Cr-Original-Commit-Position: refs/heads/master@{#428227} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: bc6fa5a73536e3ccc06fd82c1b6d5da5a712223f |
||
---|---|---|
.. | ||
bots | ||
README.txt | ||
blimp_client.gn | ||
blimp_engine.gn | ||
blimp_linux_client.gn | ||
headless.gn |
README.txt
This directory is here to hold .gni files that contain sets of GN build arguments for given configurations. (Currently this directory is empty because we removed the only thing here, but this has come up several times so I'm confident we'll need this again. If this directory is still empty by 2017, feel free to delete it. --Brett) Some projects or bots may have build configurations with specific combinations of flags. Rather than making a new global flag for your specific project and adding it all over the build to each arg it should affect, you can add a .gni file here with the variables. For example, for project foo you may put in build/args/foo.gni: target_os = "android" use_pulseaudio = false use_ozone = true system_libdir = "foo" Users wanting to build this configuration would run: $ gn args out/mybuild And add the following line to their args for that build directory: import("//build/args/foo.gni") # You can set any other args here like normal. is_component_build = false This way everybody can agree on a set of flags for a project, and their builds stay in sync as the flags in foo.gni are modified.