Patrick Steinhardt <ps@xxxxxx> writes: > Yeah, I understand that confusion indeed. I don't think that the other > proposals we've got are a lot better, either: > > - `odb_backend` was shot down because it may cause the association > that one object database has one backend. But backends are per > alternate, so there's a mismatch in expectations. I do not see where that association would come from, though. But I agree with the other objection that the word "backend" is more about implementation and less about an instance that is realized by that implementation, i.e. two such components that runs the code for a single backend may be part of a single object database. > - `odb_source` is better, but we now have the problem that we use > "alternate" interchangably in most cases where we also use > `odb_source`. This will likely lead to somewhat awkward interfaces. > > The problem with `odb_source` might eventually go away once we clearly > distinguish the "alternates" concept from the low-level mechanism to > access objects. But I'm just not certain at all whether it won't cause > more confusion when in most cases "alternates" and "sources" can be used > somewhat interchangably. > > I dunno. The more I think about this the more I start to like the > `odb_source` name. Yeah, I do not mind calling the instantiation backed by a backend implementation a odb_source. In any case, when deciding the terminology, we should look at what we currently have in the glossary and imagine how they should look like in the updated world. Currently, - "alternate object database" is described as inheriting the entirety of another "object database" (we deliberately do not say that this other object database belongs to another repository, as a standalone object database is a valid option). - "object database" is described as what holds a set of "objects". There is no complication here ;-) When treating the set of objects stored in $GIT_DIR/objects/??/ directories (i.e. "loose objects") and the set of objects stored in $GIT_DIR/objects/pack/ directory (i.e. "packed objects") as two separate odb_something, with a vision that we may add different implementations of such collection later, it would be very confusing to call each of them "an alternate". "source" may not be ideal, but it is the best among what we collectively have come up with, I think.
