Re: [PATCH 0/4] Pulling refs files

From: Daniel Barkalow <barkalow@iabervon.org>
Date: May 19, 2005, 16:00 UTC
Message-ID: <Pine.LNX.4.21.0505191147480.30848-100000@iabervon.org>
In-Reply-To: <20050519065207.GB18281@pasky.ji.cz>

On Thu, 19 May 2005, Petr Baudis wrote:

Show 15 quoted lines

> Dear diary, on Thu, May 19, 2005 at 05:19:01AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> >  2) fetching reference files by name, and making them available to the
> >     local program without writing them to disk at all.
> >  3) fetching other files by name and writing them to either the
> >     corresponding filename or a provided replacement.
> > 
> > I had thought that (2) could be done as a special case of (3), but I think
> > that it has to be separate, because (2) just returns the value, while
> > (3) can't just return the contents, but has to write it somewhere, since
> > it isn't constrained to be exactly 20 bytes.
> 
> Huh. How would (2) be useful and why can't you just still write it e.g.
> to some user-supplied temporary file? I think that'd be still actually
> much less trouble for the scripts to handle.

(2) is what is needed if the user just requests downloading objects starting with a reference stored remotely, and doesn't request that the reference be written anywhere. It is also useful because the system wants to verify that it has actually downloaded the objects successfully before writing the reference.

Note that the scripts see a higher-level interface; these are the operations that (e.g.) http-pull.c has to provide for pull.c, which builds a larger operation (determine the target hash, download the objects, write the specified ref file) out of them. It would be inconvenient for pull.c to download to a temporary file and then read the temporary file, which shouldn't normally be visible yet, to figure out what it's doing. It wants to have a function that takes a string and returns a hash, getting the value from the remote host, and it's inconvenient to deal with the disk in the middle.

	-Daniel
*This .sig left intentionally blank*