Re: [PATCH 03/16] refs: add methods for the ref iterators

[Junio C Hamano <gitster@pobox.com>]

Michael Haggerty <mhagger@alum.mit.edu> 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.