Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider support for further search engines on a scale between the existing two #296

Open
almereyda opened this issue Sep 24, 2022 · 1 comment

Comments

@almereyda
Copy link

In continuation of #13, there is a feature gap between the two offered search engines, and a resource gap in what resources are needed for providing the desired functionality.

While the list of suggested alternatives was diverse and lacked a specific review in contrast to archivy's requirements, there are two outstanding (experimental, version < 1) examples that need to be mentionned again. They can be positioned right inbetween the two existing solutions:

They should be able to combine the best of both worlds:

  • written in performant languages
  • feature complete (in comparison to RipGrep)
  • comparatively low on resource consumtion (in comparison to ElasticSearch)
@Uzay-G
Copy link
Member

Uzay-G commented Nov 29, 2022

I want to do this and appreciate you creating the issue, just have been very busy. If you'd be interested in working on this I could help you out with situation relevant code / writing too, otherwise i'd probably do this later in january or something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants