On Thu, Feb 8, 2018 at 1:33 AM, 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.
I actually prefer _next() without introducing new API. Yeah, it is slower because it must initialize next pointer (people seem dislike the patch that fixes it (i.e. with ff_next things)). But, as long as the internal doesn't use it but uses list directly, it has no problems. If speed is really a concern for users, then (B) probably is an option. Thank's. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel