I thought about this but there are a number of issues regarding HTTP
that need to be addressed:<br><br>- infinite DNS caching<br>- TCP
connect timeout/ read timeout<br>- User-Agent headers<br>- redirect
handling<br>- gzip encoding<br>
- I could go on...<br><br>... doing this 2 different ways for 2
different implementations is no fun and will lead to bugs.<br><br><div class="gmail_quote">On Thu, Oct 27, 2011 at 11:20 AM, Norman Maurer <span dir="ltr"><<a href="mailto:norman.maurer@googlemail.com">norman.maurer@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I think its a good think for netty to just be an api.. This helps to<br>
concentrate on the "core" and does not push to much dependencies etc<br>
in.<br>
<br>
Bye,<br>
Norman<br>
<br>
<br>
2011/10/27 Kevin Burton <<a href="mailto:burtonator@gmail.com">burtonator@gmail.com</a>>:<br>
<div><div></div><div class="h5">> I was looking at NETTY-333 (and have been thinking about this a bit lately)<br>
><br>
> <a href="https://issues.jboss.org/browse/NETTY-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel#issue-tabs" target="_blank">https://issues.jboss.org/browse/NETTY-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel#issue-tabs</a><br>
><br>
> ... and I think Netty should ship an official HTTP client. Not just an<br>
> example.<br>
><br>
> This would be a replacement for java.net.URL or say Jakarta HttpClient.<br>
><br>
> This would have the following advantages:<br>
><br>
> 1. More people would be able to use Netty. Right now Netty is mostly an API<br>
> for building clients and servers but this would mean that people can use<br>
> Netty out of the box for their usages.<br>
><br>
> 2. The client would use best practices and avoid common bugs. I built a<br>
> client in Peregrine that uses Netty and I've already been bitten by a few<br>
> issues I didn't anticipate.<br>
><br>
> 3. Developers would benefit from bugs fixed in the client moving forward as<br>
> they are fixed.<br>
><br>
> I also think we may need to build a different type of client that isn't<br>
> necessarily fully async.<br>
><br>
> What I did with peregrine (as it fits directly into the model I need) is<br>
> that we write to a buffer from the main thread. The buffer then writes to<br>
> Netty which then does Async IO (this is an HTTP PUT client). The great<br>
> thing about this model is that if the receiver can't handle the data being<br>
> sent to it, the client just blocks.<br>
><br>
> In our usage we often write from 1 client to N servers. Anywhere from<br>
> 10-1000 ... so the async buys us the ability to not need 1k threads doing<br>
> the IO.<br>
><br>
> Thoughts?<br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> netty-users mailing list<br>
> <a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br>
><br>
<br>
_______________________________________________<br>
netty-users mailing list<br>
<a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br>
</div></div></blockquote></div><br>