On 8/29/2015 8:56 AM, Michael Niedermayer wrote: > On Sat, Aug 29, 2015 at 02:54:06AM -0300, James Almer wrote: >> On 8/1/2015 1:31 PM, James Almer wrote: >>> On 01/08/15 7:15 AM, Nicolas George wrote: >>>> Le quartidi 14 thermidor, an CCXXIII, Reimar Döffinger a écrit : >>>>> If the goal is consistency, wouldn't an API like av_hash be the better >>>>> solution? >>>> >>>> Hear, hear! >>>> >>>> (Actually, when reading that discussion for the first time, I had not >>>> noticed it was about ciphers and not hashes, and my first reaction was >>>> "there is an unified API already".) >>>> >>>>> And yes, on-stack allocations were desired, even though they make changes >>>>> to the structs hard... >>>> >>>> Pointing the obvious: I very much doubt we ever need to change the struct >>>> used just for the implementation of a 30-years-old block cipher. >>> >>> One example i can give that took advantage of the hidden nature of the >>> struct >>> is ripemd. See aa70801aaf4038faaf673558c241fa19d5dcd181. >>> Admittedly one could blame this on my original design decision to reduce >>> code >>> duplication (The object size grew considerably after that change), but in >>> any >>> case had the struct not been opaque we would be stuck with a useless element >>> and its relevant ugly deprecation code for the next year or so, not to >>> mention >>> how to handle the transform() function pointer. >>> Also, rc4 currently can't encrypt, only decrypt. No idea if adding >>> encryption >>> functionality will require changes to the struct. >>> >>> In any case, I have no preferences. I can push the alloc() function without >>> the deprecation code, or push both and decide later if the deprecation code >>> is >>> kept or not. Which do you prefer? >>> >>>> >>>> This should be the guiding question: weight the potential hassle of a >>>> change >>>> in the struct versus the practical hassle of heap allocations. >>>> >>>> Regards, >> >> Since this set was merged from libav as-is and we're about to make a 2.8 >> release >> i want to know if we should abort the deprecations right now before the >> release, >> or leave them alone and decide later on. > > I think if theres no consens on deprecating it then its better not to > deprecate in the release
Ok, I'll remove them from the release branch once it's created. We can then decide what to do for the next. Unless someone has a better idea of how to approach this. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
