You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by "Alan M. Carroll" <am...@network-geographics.com> on 2019/07/02 18:35:47 UTC
[API] TSIOBufferReaderCopy nee TSIOBufferReaderRead
In the current documentation is the C API function TSIOBufferReaderRead which reads from an IOBufferReader in to a fixed buffer, the dual of TSIOBufferWriter. This function is not actually implemented which has caused some consternation. In working on providing an implementation, I came across an implementation for TSIOBufferReaderCopy which does (almost) the same thing but for unknown reasons was hidden from the C API. I have PR #5668 which unifies these, keeping the name TSIOBufferReaderCopy, cleaning up the implementation, and updating the documentation. It's somewhat unclear if this is really "new" API since a variant already existed and the non-existent variant was already documented, but might as well be clear and proper about it.
Re: [API] TSIOBufferReaderCopy nee TSIOBufferReaderRead
Posted by Alan Carroll <so...@verizonmedia.com.INVALID>.
Although the old name has never been used, since it wasn't just
undocumented, it was inaccessible.
On Tue, Jul 2, 2019 at 2:25 PM Sudheer Vinukonda
<su...@yahoo.com.invalid> wrote:
> +1
> I definitely like the idea of preserving the API name that's already
> existed and throwing away the unimplemented one!
> On Tuesday, July 2, 2019, 11:36:00 AM PDT, Alan M. Carroll <
> amc@network-geographics.com> wrote:
>
> In the current documentation is the C API function TSIOBufferReaderRead
> which reads from an IOBufferReader in to a fixed buffer, the dual of
> TSIOBufferWriter. This function is not actually implemented which has
> caused some consternation. In working on providing an implementation, I
> came across an implementation for TSIOBufferReaderCopy which does (almost)
> the same thing but for unknown reasons was hidden from the C API. I have PR
> #5668 which unifies these, keeping the name TSIOBufferReaderCopy, cleaning
> up the implementation, and updating the documentation. It's somewhat
> unclear if this is really "new" API since a variant already existed and the
> non-existent variant was already documented, but might as well be clear and
> proper about it.
>
>
Re: [API] TSIOBufferReaderCopy nee TSIOBufferReaderRead
Posted by Sudheer Vinukonda <su...@yahoo.com.INVALID>.
+1
I definitely like the idea of preserving the API name that's already existed and throwing away the unimplemented one!
On Tuesday, July 2, 2019, 11:36:00 AM PDT, Alan M. Carroll <am...@network-geographics.com> wrote:
In the current documentation is the C API function TSIOBufferReaderRead which reads from an IOBufferReader in to a fixed buffer, the dual of TSIOBufferWriter. This function is not actually implemented which has caused some consternation. In working on providing an implementation, I came across an implementation for TSIOBufferReaderCopy which does (almost) the same thing but for unknown reasons was hidden from the C API. I have PR #5668 which unifies these, keeping the name TSIOBufferReaderCopy, cleaning up the implementation, and updating the documentation. It's somewhat unclear if this is really "new" API since a variant already existed and the non-existent variant was already documented, but might as well be clear and proper about it.
Re: [API] TSIOBufferReaderCopy nee TSIOBufferReaderRead
Posted by Bryan Call <bc...@apache.org>.
+1
-Bryan
> On Jul 2, 2019, at 11:35 AM, Alan M. Carroll <am...@network-geographics.com> wrote:
>
> In the current documentation is the C API function TSIOBufferReaderRead which reads from an IOBufferReader in to a fixed buffer, the dual of TSIOBufferWriter. This function is not actually implemented which has caused some consternation. In working on providing an implementation, I came across an implementation for TSIOBufferReaderCopy which does (almost) the same thing but for unknown reasons was hidden from the C API. I have PR #5668 which unifies these, keeping the name TSIOBufferReaderCopy, cleaning up the implementation, and updating the documentation. It's somewhat unclear if this is really "new" API since a variant already existed and the non-existent variant was already documented, but might as well be clear and proper about it.
>