Virtual Spring Cleaning (part 2 of X) in which I release Apache::Tika::Async
In 2016, there already is a module named Apache::Tika, which does some of what my module does, but doesn't allow for asynchronous communication with the Tika process, which I need.
When putting Dancer::SearchApp together for a CPAN release, I quickly repackaged my Apache::Tika as CORION::Apache::Tika as an intermediate namespace. In the long run, the module should live on its own.
In the spirit of cleaning up, I've renamed the Tika module to Apache::Tika::Async, as it uses the Promises module and AnyEvent to abstract away the synchronicity. The API is similar but not compatible with Apache::Tika unfortunately, as my API focuses more on returning an object which holds both the metadata and the extracted content and content language instead of providing the information through several method calls.
I'm the Treasurer for the Frankfurt Perlmongers e.V. . I have organized Perl events including 9 German Perl Workshops and one YAPC::Europe.
Dude, please don't call it that!
::Async indicates IO::Async components, which when written using Future.pm interoperate well with the rest of CPAN, including POE, Mojo and provided you bypass the AnyEvent landmine, AnyEvent code too.
AnyEvent already tries to break loading IO::Async code in the same process, and the author has picked fights with the authors of all the other async systems; Promises was an interesting toy by stevan, but Future is what real code actually uses.
So please reconsider your choice of modules, but if you're going to stick with the current broken ones, please don't call it ::Async so people don't confuse it with the cpan-co-operative stuff :/
-- mst
Hmm - to be honest, to me "::Async" only indicates asynchronous, not "using IO::Async". What is your suggestion for a name that conveys the intent of providing a (Promises-based) asynchronous interface? If I used IO::Async as the backend, I would have named the module ::IOAsync or ::IO::Async.
I'm mostly using Promises as it is used by Search::Elasticsearch and my use case of Apache Tika is feeding stuff into Elasticsearch. So I have to fight with Promises anyway and can use them elsewhere at basically no cost. If there is an easy upgrade path from Promises to Future, I'm not disinclined to look at it but as I don't see Search::Elasticsearch moving to Future, I'm not really eager to go there.
Given Future already supports all of the different loops, as soon as you load an event loop at all it's effectively free.
Search::Elasticsearch chose Promises for no particular reason and the author was open to adding Future support as well; if I ever have to use it I'll likely do so since I hate having to deal with things that aren't the common standard.
If you're already forcing people to deal with AE, I'd simply call it AnyEvent::Apache::Tika so those of us who don't like software that breaks in production because the author doesn't like another CPAN module can avoid it in the first place ;)
If you're trying to use Promises to make it possible to use other event loops as well, perhaps Apache::Tika::PromiseBased or similar would be reasonable.
I dunno, but using ::Async for a module that depends on AnyEvent, which actively tries to make it impossible to use IO::Async in the same process, seems strange to me :)