I guess this is also a bit normal with software that grows over the years. One could also say that one writes the current use cases and interesting future use cases for Solr in a document and designs from scratch new - taking only the good pieces out of the existing software. Of course there is a certain amount of time where you need to maintain both - but this will be also the case for a major rewrite.
> Am 04.11.2019 um 20:58 schrieb Erick Erickson <[email protected]>: > > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
