Re: Is Boost interested in a Redis client library?

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2022-04-09 14:39:06

On Fri, 8 Apr 2022, 17:10 Marcelo Zimbres Silva via Boost, <
boost_at_[hidden]> wrote:

> Hi,
>
> I am the author of Aedis, a Redis client library built on top of
> Boost.Asio that provides communication with the Redis Server over its
> native and most recent protocol RESP3 [1].
>
> It is an implementation from scratch that depends only on other Boost
> Libraries (Asio, Variant2, Optional, etc.) and targets C++14.
>
> I would like to propose it for inclusion in Boost in the near future
> if there is enough interest, at the moment I am interested in early
> feedback as I finish writing it (writing docs, improving tests etc.)
>
>   - Do you think this library would be valuable to Boost?
>

Although I am not a Redis user, I believe
it would be valuable in Boost. I think
many users would appreciate robust
interfaces to widely used systems.
I have proposed a MySQL client, similar
to your library.

  - Was the documentation helpful to understand what Aedis provides?
>

I have had a quick glance at the docs
and have some questions: which is the
API you expect most of your users will
be using? The higher level or the lower
level? If it's the former, I would move that
section to the beginning. I would also
like to know the advantages of one API
vs the other, like when would I use the
lower-level vs the higher-level and why?

  - Does the design look good?
>

I would like to understand what are the
client::async_run mechanics - when does
that function complete and under what
circumstances does it error?

It appears that client::send is using some
sort of queue before the messages are
sent to Redis, is that thread-safe? How
can I know if a particular operation
completed, and whether there was an
error or not? I would also like more info
on when the callbacks of the receiver
are invoked.

In general, I feel that higher level interface is forcing me use callback
based code, rather than following Asio's
universal async mode. What is the
design rationale behind that? Would it
be possible to have something like
client::async_connect(endpoint,
CompletionToken)?

  - Any feedback is welcome.
>
> Link to Aedis Documentation:
> https://mzimbres.github.io/aedis/
>
> Link to the github project:
> https://github.com/mzimbres/aedis
>
> If you never heard about Redis, this is the best place to start:
> https://redis.io
>
> Regards,
> Marcelo
>
> [1] https://github.com/antirez/RESP3/blob/master/spec.md
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>