#18 Higher-level store interface

Otwarty
otworzone 1 dzień temu przez scossu · 0 komentarzy
scossu skomentował 1 dzień temu

There is a lot of feature checking and conditionals when accessing store interface functions, because some of those functions are only defined for store types that support certain features. Moreover, the correlation between features and functions implemented is documented, but not enforced. Calling a non-implemented interface function causes a segfault.

This ticket is to develop functions in store.c to wrap individual store interface functions and provide fallback based on feature flags, to return no-ops or LSUP_NOT_IMPL_ERR as a fallback, thereby enforcing the dependency of certain functions on feature flags without the API user worrying too much about it.

The store interface might be made private as a result of this, but this is not necessary and it needs additional functions to expose other metadata, e.g. feature flags, interface name, etc.

There is a lot of feature checking and conditionals when accessing store interface functions, because some of those functions are only defined for store types that support certain features. Moreover, the correlation between features and functions implemented is documented, but not enforced. Calling a non-implemented interface function causes a segfault. This ticket is to develop functions in `store.c` to wrap individual store interface functions and provide fallback based on feature flags, to return no-ops or `LSUP_NOT_IMPL_ERR` as a fallback, thereby enforcing the dependency of certain functions on feature flags without the API user worrying too much about it. The store interface might be made private as a result of this, but this is not necessary and it needs additional functions to expose other metadata, e.g. feature flags, interface name, etc.
Zaloguj się, aby dołączyć do tej rozmowy.
Brak kamienia milowego
Brak przypisania
1 uczestników
Ładowanie...
Anuluj
Zapisz
Nie ma jeszcze treści.