Elastica is an upstream library: http://elastica.io/

In T99755#1298225, @Legoktm wrote:

Elastica is an upstream library: http://elastica.io/

Yes, but the Elastica extension (which extends the Elastica library) is not: http://www.mediawiki.org/wiki/Extension:Elastica

I don't know if this will be directly possible without heavy refactoring of the upstream Elastica library and the SpecialSearch page.

When you use async/await in a function that function now returns Awaitable<T> instead of whatever it was returning previously. In this case we would probably extend Elastica\Transport\HttpTransport to override the exec() method, but then that method returns an Awaitable<Elastica\Response>, rather than an Elastica\Response directly. All of the functions in the stack between our calling code and the AbstractTransport then also need to become async, awaiting on the async method they call. To generate the interface while this async code is working, the code that generates the interfaces also has to be marked async. It doesn't have to be async IO, it can simple give up to the async scheduler via await RescheduleWaitHandle::create(0, 0); There isn't a ton of interface to be drawn though, with the exception of the skin. But the skin is the last thing to be drawn and would also have to be made async.

In a short talk with one of the hhvm developers, they suggested there should be a single Awaitable::join() call in the entire application at the top level. In short, my limited understanding of async in hhvm is that it is very invasive, everything you want to do at the same time has to be async and converted to hacklang (if only superficially). The amount of interface drawn in SpecialSearch is pretty minimal, I'm not sure it would be a big win here.

I should add it's not really the Elastica library changes that will be particularly hard, although it can't be done nicely with inheritence. For the most part that is just adding async and await keywords in all the right places. More difficult will be that the core SearchEngine and SpecialSearch also have to be converted to hacklang and made await/async aware. This is because CirrusSearch isn't responsible itself for any of the interface that is being drawn.

I did some investigation over the weekend, performing a (mostly broken) port of the Elastica client library to use hacklang and async/await. The (mostly broken) code for that can be found on my github[1]. This is mostly a proof of concept, if we wanted to move forward i would need to spend several more days just getting all the tests to pass for this async version of Elastica.

[1] https://github.com/ebernhardson/Elastica/tree/async