Closed gperciva closed 2 years ago
I've reconsidered having the pair of:
storage_read_add_name_cache()
storage_read_add_data_cache()
We need a public API function for storage_read_add_name_cache()
-- with potentially a different name, like storage_read_request_to_cache()
or storage_read_add_data_for_this_name_to_the_cache_if_you_see_it()
-- but we don't need a public function for _add_data_cache()
.
With that in mind, I'd suggest that we name the latter function what it'll end up being inside storage_read_cache.h
... probably storage_read_cache_add_data()
, unless a better name comes to mind.
Rebased for review, updated the top comment. PR 1/3 towards an independent storage_read_cache.[c,h]
.
Ok, LGTM.
Rebased; this changed the history of the last 3 commits of this PR.
Some tidbits:
We want to reserve "
storage_read_cache*
" for future use, so rename some functions.Not part of this branch, but the idea is to end up with
storage_read_cache_add_name() storage_read_cache_add_data()
with
storage_read_add_name_cache()
being the public API at the storage level, with possibly a different name such asstorage_read_request_to_cache()
orstorage_read_add_data_for_this_name_to_the_cache_if_you_see_it()
-- but we don't need a public function for_add_data_cache()
.I don't mind using "hash" or "file" instead of "name", but I'll note that the storage_read API uses
(char class, const uint8_t name[32])
anduint8_t classname[33]
all over the place, so I figured that "name" was the best thing to call it. (Or "classname", I suppose, but I don't think the "class" adds anything useful to the function name, given thatchar class
is in the argument list anyway.)you might prefer to have the last two commits (regarding the "should we cache this data" and
storage_read_cache_add_data
) together.a867831 shows a bunch of changes, but if you look at it with
--ignore-space-change
, we can see that the non-whitespace changes are trivial: