From: Taylor Blau <me@ttaylorr.com>
Date: Thu, 22 Jan 2026 23:47:33 GMT
Subject: Re: [PATCH v3 03/14] object-file: extract function to read object info from path
Message-ID: <aXK3FV8MoEBeAcu9@nand.local>
In-Reply-To: <aXHI_Q_88q1aAXlW@pks.im>

On Thu, Jan 22, 2026 at 07:51:41AM +0100, Patrick Steinhardt wrote:
> On Wed, Jan 21, 2026 at 07:04:02PM -0500, Taylor Blau wrote:
> > On Wed, Jan 21, 2026 at 01:50:19PM +0100, Patrick Steinhardt wrote:
> > > Extract a new function that allows us to read object info for a specific
> > > loose object via a user-supplied path. This function will be used in a
> > > subsequent commit.
> >
> > I think that I'm a tad unsure of this interface. I understand that for
> > the existing object storage mechanism that having a path makes sense:
> > loose objects are stored in files which are referenced by their path.
> >
> > But this feels like a leaky abstraction to me. If we are dealing with an
> > object store implementation that uses entries in a database, or
> > arbitrary blob storage, do they have an equivalent concept of "path"?
>
> It is leaky indeed, but that should be fine given that it's local to the
> loose object backend anyway. So no other object storage format uses or
> even sees it.

If it's local to the loose object backend then I agree it's OK here.
I think I was unclear that was the case since I saw "path" being used in
conjunction with the generic "odb_source" type.

Thanks,
Taylor