Shipping an official HTTP client in Netty (NETTY-333)

[Kevin Burton]

If netty were to remain just an API then linking to people that use the
higher level API would be beneficial.

I don't really want to maintain the HTTP client I wrote for Peregrine but I
didn't have any solution for HTTP PUT...

Kevin

On Thu, Oct 27, 2011 at 4:19 PM, Vibul Imtarnasan <vibuli at gmail.com> wrote:

> Hi,
>
> I too like the fact that Netty is just an API without too many
> dependencies.
>
> Maybe a solution is to list and link to the different apps/libraries that
> use Netty on the current web site or in a wiki somewhere?  Although there
> will be nothing "official", I'm sure users will congregate round the apps/libraries
> that best suit their different needs.
>
> Is there such a page?  If not, would it be beneficial to create one?
>
> Regards
> Vibul
>
>
> On 28 October 2011 05:20, Norman Maurer <norman.maurer at googlemail.com>wrote:
>
>> I think its a good think for netty to just be an api.. This helps to
>> concentrate on the "core" and does not push to much dependencies etc
>> in.
>>
>> Bye,
>> Norman
>>
>>
>> 2011/10/27 Kevin Burton <burtonator at gmail.com>:
>> > I was looking at NETTY-333 (and have been thinking about this a bit
>> lately)
>> >
>> >
>> https://issues.jboss.org/browse/NETTY-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel#issue-tabs
>> >
>> > ... and I think Netty should ship an official HTTP client. Not just an
>> > example.
>> >
>> > This would be a replacement for java.net.URL or say Jakarta HttpClient.
>> >
>> > This would have the following advantages:
>> >
>> > 1. More people would be able to use Netty.  Right now Netty is mostly an
>> API
>> > for building clients and servers but this would mean that people can use
>> > Netty out of the box for their usages.
>> >
>> > 2. The client would use best practices and avoid common bugs.  I built a
>> > client in Peregrine that uses Netty and I've already been bitten by a
>> few
>> > issues I didn't anticipate.
>> >
>> > 3. Developers would benefit from bugs fixed in the client moving forward
>> as
>> > they are fixed.
>> >
>> > I also think we may need to build a different type of client that isn't
>> > necessarily fully async.
>> >
>> > What I did with peregrine (as it fits directly into the model I need) is
>> > that we write to a buffer from the main thread.  The buffer then writes
>> to
>> > Netty which then does Async IO (this is an HTTP PUT client).  The great
>> > thing about this model is that if the receiver can't handle the data
>> being
>> > sent to it, the client just blocks.
>> >
>> > In our usage we often write from 1 client to N servers.  Anywhere from
>> > 10-1000 ... so the async buys us the ability to not need 1k threads
>> doing
>> > the IO.
>> >
>> > Thoughts?
>> >
>> > _______________________________________________
>> > netty-users mailing list
>> > netty-users at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/netty-users
>> >
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20111027/a6bc2b1e/attachment.html