Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> Actually, maybe we will never have to rewrite all callers. I rather
> think that we will retain one simplified API for dealing with "*this*
> repository's references" and a second for dealing with other repos' refs.
Yeah, I think the similarity with the multiple in-core index support
Peff brought up holds true here as well.
>> [...]
>> The caching of already read refs is a responsiblity of each ref
>> backend in the current codebase. I am not sure if that is a good
>> placement, or a single implementation of the caching layer should
>> instead sit on top of any and ll ref backends.
>
> I still dream about having compoundable reference backends, in which
> case, ultimately, a "CacheReferenceStore" instance would optionally wrap
> on top of an arbitrary other "ReferenceStore" instance (so to speak) to
> give it caching functionality.
I am not sure if we need or want the fully stackable backends, but I
can see that the implementation of the API could be structured like
so:
(1) Users of API would interact solely with the in-core caching
layer when creating, reading, modifying, enumerating and
deleting refs and contents of their logs. The caching layer
has a handle for each in-core representation of a "repository",
and there is a single default one, i.e. our repository. Also
there is a way to ask for the in-core represention of a
"repository" for submodules.
(2) An instance of an in-core "repository" caching layer knows what
"storage backend" the repository uses and this is used to
dispatch the requests to suitable backends. The caching layer
would be responsible for maintaining the validity of in-core
cache it keeps while it relays the requests.
(3) The implementation of for_each_ref_in_submodule() family of
functions may need to be restructured; having to have the
backend method for them would force storage backends to be
aware of "other" repositories. Other "only in this repository"
methods David and Ronnie's topics abstracts out of the files
backend would remain the same.
which may be clean and flexible enough for our purpose.
Just to reiterate to avoid misunderstanding, I do not think that
kind of restructuring has to be a prerequisite for the current
effort to allow multiple backends, though.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html