On date Thursday 2011-04-07 00:18:48 +0000, Ronald S. Bultje wrote: > Hi, [...] > > Another point is that an application may need to implement an ad-hoc > > access protocol, this is not an hypotetical need as you can find many > > of such requests in the libav-user archive. I can understand that the > > API may need to be made hidden for the moment while it is reworked, > > but then at some point it will be useful to make the protocol struct > > public again. > > Let's consider that when a real usecase arises. > > The hypothetical "I need a custom protocol" means it's either to embed > lavf demuxers in a non-FFmpeg/Libav framework, for which AVIOContext > is better suited,
yes > or for stuff that should be inside FFmpeg/Libav anyway. No, requirements can be pretty weird these days, you may need to access another ad-hoc process, or use a private protocol which is not useful enough to be embedded into the framework. This applies to most configured elements in FFmpeg/Libav, we implement the stuff which is publically useful but there are a lot of ad-hoc components which are better implemented at the application level. > > Another possibility is to keep the struct public and warn the user in > > big capital letters that the interface is not considered stable yet > > and can break at each moment (nasty solution from the user POV but yet > > better than having to copy an header in your app). > > Manually include url.h is still possible. In fact, all our protocol > handlers do it. :-). > > > BTW "url" is a crappy prefix in this context and higly misleading > > (they are not URL parsing routines after all), I suggest something > > along the line of (ff|av)proto, the fact that most protocols deal with > > urls is purely accidental. > > The great thing is that it's internal API now, we can fix/change it. > I'd really like that. This also applies to other parts, including > libavfilter, where exposing an infant API can make progress a lot > slower than it should be. This is engineering, so we don't have The Perfect Solution but a set of constraints and tradeoffs. I agree that exposing an unstable interface is not safe, but unnecessarily limiting the functionality of the library is worse (point of view of external user/developer vs. point of view of packager/maintainer). Of course the final evaluation much depends on the value that you assign to each feature. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
