[pacman-dev] callback functions

Xavier shiningxc at gmail.com
Wed May 14 05:46:29 EDT 2008


2008/5/14 Nagy Gabor <ngaba at bibl.u-szeged.hu>:
> >
>  http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-g2.git;a=commitdiff;h=9bde1c36eb10ff121f7de5bb34ade2a704f49c82
>  > > (nice jab there, pretty mature)
>  >
>  > oh well, different targets. this is just a decision. we try to keep a
>  > stable api, you don't. both has benefits. and at the end users can
>  > choose. that's the best :)
>  >
>
>  IIRC, this was reverted, but that is just one more argument to your 'not stable
>  API' "campaign".
>

It doesn't make any sense to stabilize such a crappy API.
But just as reminder, the API remains stable between minor releases
(3.x.y), but not between major releases (3.x)

About the dltotal thing, Dan indeed reverted it, but we need to add
that feature back with another way.
We currently have this callback :
void cb_dl_progress(const char *filename, int xfered, int total)
Dan suggested to add another one 2 days ago, I believe it was something like :
void cb_dl_total_progress(int xfered, int total)
But I already forgot. Dan, can you confirm this? :)

>  In my opinion the parameters of callback functions should be reworked (warning,
>  API change ;-). My preferred solution would be putting one param, a pointer to a
>  complicated union or whatever, which can be accessed via
>  alpm_info_get_xfered(ptr) etc. thus making it much more flexible. Thoughts?
>

This might not be a bad idea, any work that would allow us to get rid
of these TODO in callback.c is welcome :
/* TODO this is one of the worst ever functions written. void *data ? wtf */
        /* TODO we take this route based on data2 being not null? WTF */




More information about the pacman-dev mailing list