If Curator would make that easier and we’re doing major surgery anyway….
But yeah, a nifty, new, more modern tool isn’t going to magically help if the design is flawed. Or, if I’m putting my philosophical hat on, code doesn’t get gnarly intentionally. It gets gnarly because there are a bunch of problems to be solved and you don’t know what they are until you run into them. And it’s always a tension between fixing it enough to get by and fixing it by refactoring/redesign. But eventually “fixing it enough to get by” totters under it’s own weight and becomes increasingly fragile and you must take the hit and redo major portions of it. The questions now are: 1> are we at that point? 2> are we going to put the effort into rewriting some of the worst offenders? > On Nov 4, 2019, at 1:28 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > Figuring out a better overall algorithmic & data structure design that's an > order of magnitude improvement seems far more important than swapping out > libraries. And I say this as a Curator fan and committer. ;) > > On Mon, Nov 4, 2019 at 11:44 AM Erick Erickson <erickerick...@gmail.com> > wrote: > Bram: > > Using Curator has been proposed before. It would require significant > refactoring b/c of how deeply entwined raw ZK is in the code. That said, if > we’re going to do major surgery it may be the right time to consider it. > > Erick > > > On Nov 4, 2019, at 9:24 AM, Bram Van Dam <bram.van...@intix.eu> wrote: > > > >> SolrCloud is sick right now. The way low level Zookeeper is handeled > > > > On an unrelated project, I've stopped using "raw" ZK client access and > > have switched to Curator. The API is a fair bit easier to work with, and > > it results in less ugly code. I realize that this won't go very far in > > resolving more fundamental issues, but it might be something that can > > help improve the shape of the code. > > > > - Bram > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
