Hi,

There has for sure been interest since CDCR disappeared. Given the close 
integration with Solr and its small footprint, I’m supportive of this becoming 
a Solr module with URP and a standalone app in the main repo.

So the code can be cleaned up, documented and migrated over in a few PRs as any 
other feature. 

We need integration tests as well of course, don’t know how that looks like 
with Kafka and all, but it is crucial that new components have test coverage.

What other queues could be considered? Would it be natural to support the 
managed queues of the major three public cloud providers?

Jan Høydahl

> 9. sep. 2023 kl. 17:58 skrev Anshum Gupta <ans...@anshumgupta.net>:
> 
> I wouldn't term people who work at a particular company as <company name>
> committers. I'm reasonably sure when folks contribute to the project they
> wear their ASF hat. If they don't, they should.
> 
> Like most other features, this one also is a result of the need by users of
> the project. I completely agree it's been experimental so far, and the
> intent isn't to release it straight off in the shape it exists right now
> but for the code to move first. The code is certainly good to be used
> functionally at scale, but we need to clean it up and bring it up to follow
> the best practices that we follow for the main repo. As someone who's been
> involved with this actively, I can certainly say that there has been some
> interest from the broader community. I hope those folks participate in this
> conversation :)
> 
> As Houston and Mark said, this is a fairly simple and isolated code base.
> There's an update request processor, and a standalone application just like
> the Prometheus Exporter. I'd actually created this separate repository with
> an intent to have independent release cycles but over the course of time I
> am convinced that it would be more efficient and reasonable for this code
> to not be a part of the sandbox. This doesn't affect Solr core in anyway
> and would be an optional component that folks wouldn't even need to
> download as we wouldn't include this in the slim distribution.
> 
> @Ishan - I hope that answers some of your questions. If not, we can perhaps
> get on a quick call and discuss this.
> 
> -Anshum

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Reply via email to