[pacman-dev] [PATCH] Add a fetch callback to allow front-end download support

[Aaron Griffin]

On Thu, Feb 19, 2009 at 1:11 PM, Sebastian Nowicki <sebnow at gmail.com> wrote:
>
> On 20/02/2009, at 2:03 AM, Aaron Griffin wrote:
>
>> On Thu, Feb 19, 2009 at 12:55 AM, Sebastian Nowicki <sebnow at gmail.com>
>> wrote:
>>>
>>> This allows a frontend to define its own download algorithm so that the
>>> libfetch dependency can be omitted without using an external process.
>>> The callback will be used when if it is defined, otherwise the old
>>> behavior applies.
>
> Just noticed it should be s/when//.
>
>> I like this, but my first thought is: why not extrapolate our current
>> downloading as a "fetch callback" too? That way the check just needs a
>> "!= NULL" before calling it, and it can be done on config parsing:
>
> I had the same idea, but decided to leave it as is so that the two methods
> can be distinguished. Re-thinking it, they don't really need to be
> distinguished (in alpm), since the callback is used if the front-end
> specifies it either way, and the default could be the internal download
> function. It's quite late atm so I won't send the patch just now ;).
>
>> //in initialization
>> #ifdef INTERNAL_DOWNLOAD
>>  fetchcb = internal_fetch;
>> #else
>>  fetchcb = NULL;
>> #endif
>> ...
>> ...
>> // in config parsing
>> if(strcmp(blah, "XferCommand") == 0) {
>>  fetchcb = use_xfercommand;
>> }
>
> Indeed, much simpler. It seems this makes download() unecessary as it would
> only call handle->fetchcb(), and as far as I can tell it only gets called in
> _alpm_download_single_file() and alpm_fetch_pkgurl().

Yeah, we'd just need to make sure that there is a "if fetchcb == NULL)
{ error and return 1 }"
We don't want to fail early on this, as a download function isn't always needed