One possible improvement remains here: in streaming mode, HTTPSFuture will not "Accept-Encoding: gzip" and can not inflate responses. Today, this only applies to arc download.

There's also one minor related concern in PHI1638 that I want to take care of here, since it's adjacent.

In fairness, "SetInputFilter DEFLATE" is documented as uniquely opinionated, if you catch this box and read between the lines a little bit:

A grand aventure in PHI1679 led to identifying the Apache "SetInputFilter DEFLATE" directive as a problem with implementing compression.

"FutureGraph" is dead. Long live "HardpointEngine".

Generators can't "return" until PHP 7:

PHP has a setting called post_max_size. If a POST request is larger than this size, PHP does not populate $_POST or $_FILES.

In T11968#251717, @epriestley wrote:

XHPAST currently can't build an AST for $result = yield ..., even though this is a valid construct. This is probably a straightforward fix.

XHPAST currently can't build an AST for $result = yield ..., even though this is a valid construct. This is probably a straightforward fix.

I have some code which runs and looks plausible (i.e., not covered in piles of callback garbage), at least:

Here's an actual example of loadHardpoints($objects, $hardpoint):

In the specific case of the Hardpoints, we currently often have code which loads objects but doesn't do anything with them. For example, most Query classes use didFilterResults() to fill things-that-sure-look-like-hardpoints, but few do anything with the results.

The core idea in D5104 + D5105 is that $future->resolve() and id(new FutureIterator(array($future)))->next() (like, roughly) execute meaningfully different code paths.

Somewhere in experimental or wilds, I introduced ArcanistConduitEngine. This has some weird fake future stuff going on, so this is probably now ripe.

Probably require PHP 5.4 regardless.

A problem in moving forward here is that we ultimately do very little complex data access in Phabricator, and what complex data access we do perform can often be faked. We likely have more use cases in Arcanist and provisioning code: API calls are slower, workflows are more parallel/interactive, and we can't just fake it all with AJAX.