Discuss database solution for address book, netdb, profiles, etc.

[anonimal]

By submitting this issue, I confirm the following:

• I have read and understood the contributor guide.
• I have checked that the issue I am reporting can be replicated or that the feature I am suggesting is not present.
• I have checked opened or recently closed pull requests for existing solutions/implementations to my issue/suggestion.

Place an X inside the bracket to confirm

• I confirm.

---

Discussed in today's meeting. Details to come.

[anonimal]

LMDB, it's the place to be, just ask @hyc.

[anonimal]

lmdb++ seems like a viable candidate (IMHO). @hyc says he hasn't looked at it so he doesn't have an opinion (his own implementation is in the monero tree). @vtnerd agrees with me in that it looks fairly decent. @guzzijones will probably like the fact that it's a wrapper (as would I) but I have yet to confirm with him.

[vtnerd]

FWIW, I would write my own simple wrapper just for necessary bits. But at a glance the implementation at least looked sane; aggressive use of noexcept, no unnecessary virtual methods, etc. It was mostly just a wrapper that cleaned up on scope and added some helper functions for copying to STL containers.

[guzzijones]

openldap appears to have a lot of what we would need for the address book use case and the host file use case.

[coneiric]

@guzzijones @vtnerd I'm refactoring parts of the HTTP client and address book (#812), and thinking about how to rewrite features to be agnostic about storage.

@anonimal suggested that pimpl may be one way to hide implementation details, but won't be necessary until a compilation firewall is needed. This concept is new to me, so I don't know how to make that judgement call just yet. In the interim, a generic interface was suggested.

How would all of you advise implementing a generic interface to be modular and independent of storage implementation, with the least amount of refactoring/maintenance overhead? (mb this is blue-sky thinking)

As an example, the HTTP proxy jump service stores new addresses in the address book. There is the AddressBookStorage class, should I refactor this class to a base class with derived classes for different storage implementations (e.g. filesystem, database, openldap)?

Would an lmdb++ database refactor into / support a later openldap implementation, or is that a design decision that needs to be made first?

[anonimal]

How would all of you advise implementing a generic interface to be modular and independent of storage implementation, with the least amount of refactoring/maintenance overhead?

That's a generic C++ question out of scope to this issue. If I have to tell you how to write it, I may as well write it myself when I get to resolving this issue.

While you continue learning C++, you can dive into a local branch and start hacking away. If you want me to look at anything, ping me here or on IRC.

In terms of abstraction, simply note the various points of filesystem access and ultimately hide the implementation.

Would an lmdb++ database refactor into / support a later openldap implementation, or is that a design decision that needs to be made first?

This could be good case for pimpl if we want to profile real-time lmdb++ performance versus a custom implementation.

[anonimal]

NOTICE: THIS ISSUE HAS BEEN MOVED TO GitLab. Please continue the discussion there. See #1013 for details.