offa
I don't see reasons against multiple apps for the same purpose. Every user has it's own requirements or preferences – one might base it's choice on features, one by design...
Could you have a look at the PR @tgalal?
*Closed due to inactivity*
Please let me know if there are any objections.
Thanks for your PR! I have some comments, but my (personal) overall opinion is, that this adds quite some complexity to everyone just to handle a single (less used?) transport....
> You'd obviously be completely within your rights to do so. Unfortunately, that would be problematic from my perspective. To explain why, it might be helpful to understand the use-case...
There are two little things that are worth merging independently as they provide profit already: Using uint16 ports (TCP / UDP ctor) and the `resolve()` related changes (= the try-catch...
Some thoughts (not necessarily good though): - Implementing an additional batching strategy beside by-count - Implementing send as strategy in general (eg. no batching, by-count, by-size) - Since it's a...
> Since it's a line protocol – terminated by a newline – and tags / fields don't support \n; send as many lines as fit into in a packet, then...
Thanks for the report. This is similar to #86. I'm going to plan this for the next release.