On Wednesday 2011-04-06 17:13:34 -0400, Ronald S. Bultje wrote: > Hi, > > On Tue, Apr 5, 2011 at 4:14 AM, Stefano Sabatini > <[email protected]> wrote: > > On date Tuesday 2011-04-05 00:32:07 +0200, Anton Khirnov wrote: > >> On Mon, Apr 04, 2011 at 11:21:51PM +0200, Stefano Sabatini wrote: > > [...] > >> > Stupid question, what's wrong with av_protocol_next()? > >> > > >> > And why to drop the listing of the protocol features in > >> > show_protocols()? > >> > >> We're making the whole unbuffered API, including URLProtocol, private, > >> so an external app won't have any access to members of URLProtocol. > > > > What's the point of it? Also this is preventing an application to > > write a custom access protocol (not to mention this is breaking > > backward compatibility and reducing functionality as in this patch). > > Cleanup, of course. It's nice to be able to list all input/output > formats, but seriously, no external app should use this API (not this > function specifically - the whole API), and it's better to hide it > then. > > How to list them? Well, maybe we need a get_input/output_protocols() > function that returns a pointer to char[]s. I don't really know. But > that doesn't require access to the whole > URLProtocol/URLContext/url_*() API.
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. 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). 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. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
