On Fri, 2011-10-07 at 09:40 +1100, Greg Wilkins wrote:
> Sure, this is my option 3 above. I still question if the effort for
> streams will be worthwhile given that arbitrary limits already exist,
> but if others feel it is necessary then supporting both APIs is best.
>
> +1 for CharBuffer and ByteBuffer
Ok. That "option 3" is certainly the most elegant in all cases, with no
changing of the input, and the possibility to respect the wishes of the
user on output. Although you say this should be abstracted away, I would
still prefer an API with full knowledge of frames.
If the frames can really be edited at will by the container, then it is
technically possible to use a buffer API only, but this could still be
less efficient for certain apps maybe ?
The output will need some listener callback to control blocking (the
application could write an arbitrary amount of buffers very quickly
otherwise, with no way to know if they have be sent already), so
ultimately this is quite similar.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc