Patrick Steinhardt <ps@xxxxxx> writes: > The `object_directory` structure is used as an access point for a single > object directory like ".git/objects". While the structure isn't yet > fully self-contained, the intent is for it to eventually contain all > information required to access objects in one specific location. > > While the name "object directory" is a good fit for now, this will > change over time as we continue with the agenda to make pluggable object > databases a thing. Eventually, objects may not be accessed via any kind > of directory at all anymore, but they could instead be backed by any > kind of durable storage mechanism. While it seems quite far-fetched for > now, it is thinkable that eventually this might even be some form of a > database, for example. > > As such, the current name of this structure will become worse over time > as we evolve into the direction of pluggable ODBs. Immediate next steps > will start to carve out proper self-contained object directories, which > requires us to pass in these object directories as parameters. Based on > our modern naming schema this means that those functions should then be > named after their subsystem, which means that we would start to bake the > current name into the codebase more and more. > > Let's preempt this by renaming the structure. There have been a couple > alternatives that were discussed: > > - `odb_backend` was discarded because it led to the association that > one object database has a single backend, but the model is that one > alternate has one backend. Furthermore, "backend" is more about the > actual backing implementation and less about the high-level concept. > > - `odb_alternate` was discarded because it is a bit of a stretch to > also call the main object directory an "alternate". > > Instead, pick `odb_source` as the new name. It makes it sufficiently > clear that there can be multiple sources and does not cause confusion > when mixed with the already-existing "alternate" terminology. > > In the future, this change allows us to easily introduce for example a > `odb_files_source` and other format-specific implementations. Sorry for being pedantic (but I guess this series is all about naming anyway, so better get it right), but wouldn't this be `odb_files_backend`? -- Cheers, Toon
