On Wed, 7 Feb 2018 19:33:15 +0100 Nicolas George <geo...@nsup.org> wrote:
> James Almer (2018-02-07): > > Since reverting would be dirty, I'd prefer if we keep the discussion > > about the desired API going and then apply the needed patches on top of > > the current tree. > > As long as we don't take weeks to do it (and do it before a release is > > tagged), any kind of change to what is already committed is ok. > > Yes, that is exactly what I meant with "virtually revoked". Let us hope > people will not start using the API before we stabilize it. > > But I would like that people be more careful with it. Twice in a few > days have patches been pushed while there were outstanding objections > about the API. If it had been done on purpose, I think it would have > been ground for revoking git commit rights. > > Now, as for the possible APIs for iterating: > > (A) this one using an opaque pointer and a _next() call; > > (B) using an index; > > (C) returning the whole list at once in a newly allocated array. > > Are there any missing? > > I am rather in favour of (C), because it is the one that puts the least > constraint on the internal implementation. And it is very convenient for > the caller. It's the least convenient for both caller and implementation, because suddenly there's a cost associated with getting the list, and the possibility that getting the list can fail. Speaking as someone who has to use the new API. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
