https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35920
--- Comment #28 from Tomás Cohen Arazi (tcohen) <[email protected]> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #3) > I like the concept. > > Given the discussion Marcel is driving around rabbit vs. polling, why not > create some base class and then different classes implementing each > communication mechanism? That way each use case would be self-contained and > maintainble (i.e. one can fix a bug without possibly breaking the other use > case, etc). > > Something like: > > Koha::Worker > Koha::Worker::STOMP > Koha::Worker::Polling > > and then the `background_jobs_worker.pl` script would just call > > > if ( C4::Context->use_stomp ) { > Koha::Worker->new( 'STOMP' )->run(); > } > else { > Koha::Worker->new( 'Polling' )->run(); > } This was my original idea, pretty much what David suggests. I was trying to write it this morning when I hit a roadblock: I wanted to prepare it to support delayed retries, and figured it would require manually installing and maintaining the setup for the delayed queue plugin (not shipped in Debian). And I understood this would need to be set to not-default for the general public because of that. So a niche use case with too little gain so far. So the question is: who’s gonna maintain that? Implementing a feature would require doing it in both for sure. Who would do it? Those are my questions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
