Re: NIO based connection manager impl / async HttpClient
--- "Asankha C. Perera" <[EMAIL PROTECTED]> wrote: ... > Synapse uses Apache Axiom to parse XML data on > demand. I think this is > slightly different from what you are trying to > achieve.. ? Well, Axiom is a tree model (incrementally built one), and uses regular blocking streaming parsers. That is, it doesn't really parse anything itself but delegates to a parser. But as long as Axiom could itself operate in non-blocking way (which may require some changes, I am not familiar enough with Axiom to know), it could use a non-blocking parser. This might not be super-hard, if Axiom can use SAX parsers too (in addition to default Stax ones), because that already does inversion-of-control (tree builder has to decompose sequence from events). -+ Tatu +- You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO based connection manager impl / async HttpClient
Oleg Sorry for being late to reply.. I would like to start working on a NIO based version of the connection manager sometime in the coming days / weeks. A connection manager implementation for non-blocking HTTP connections can be potentially useful for both Synapse and LimeWire, and probably other projects as well. Essentially an NIO based connection manager implementation is the only missing piece of functionality preventing us from developing a full-blown asynchronous version of HttpClient. +1 to this and Synapse is interested There is a few points, however, I would like to discuss with the HC community before I go ahead with these plans (1) First off, are there any objections to developing an NIO connection manager within HC? Not from me (2) If there are no objection to hosting this code here, shall NIO based client-side components be developed as a project distinct from traditional HttpClient with a separate release cycle, probably even starting with the release version 1.0, or shall we develop it as a module of HttpClient sharing the same release cycle? I personally would prefer it as a module.. but am fully ok even if its another project (3) Anyone interested in getting involved in the early stages of development and helping me define the API and the component architecture for the NIO connection manager? I haven't been able to do much with HttpCore lately due to other stuff, but am interested to help out anyway I can.. at least in review and initial testing etc. I will not be available on Mail from 9th to around 15th as Sri Lanka will be celebrating the local new year during this time :-) thanks asankha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO based connection manager impl / async HttpClient
I know this is slightly off-topic for the list, but since it is related to non-blocking aspects of data transfer I hope it's ok. I have been working on a non-blocking xml parser (feed data when it becames available, see if new events can be parsed and returned), and was thinking that it would be a good fit for non-blocking data transfer components (or put another way: without non-blocking i/o there aren't many benefits to non-blockin parsing). So, if anyone is interested for this, feel free to email me and I can give more info. -+ Tatu +- Tatu, I suspect this is something Synapse folks might be interested to hear about. Tatu Synapse uses Apache Axiom to parse XML data on demand. I think this is slightly different from what you are trying to achieve.. ? asankha
Re: NIO based connection manager impl / async HttpClient
On Wed, 2008-03-26 at 11:04 -0700, Tatu Saloranta wrote: > --- Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > Folks, > > > > I would like to start working on a NIO based version > > of the connection > > manager sometime in the coming days / weeks. A > > connection manager > > implementation for non-blocking HTTP connections can > > be potentially > > useful for both Synapse and LimeWire, and probably > > other projects as > > well. > ... > > I know this is slightly off-topic for the list, but > since it is related to non-blocking aspects of data > transfer I hope it's ok. > > I have been working on a non-blocking xml parser (feed > data when it becames available, see if new events can > be parsed and returned), and was thinking that it > would be a good fit for non-blocking data transfer > components (or put another way: without non-blocking > i/o there aren't many benefits to non-blockin > parsing). > > So, if anyone is interested for this, feel free to > email me and I can give more info. > > -+ Tatu +- > Tatu, I suspect this is something Synapse folks might be interested to hear about. Oleg > > > > > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO based connection manager impl / async HttpClient
On Wed, 2008-03-26 at 11:21 -0400, Sam Berlin wrote: > > (1) First off, are there any objections to developing an NIO connection > > manager within HC? > > Not from me -- I think it definitely falls within the scope of the > project, given that NIO components already exist and seem to be used > by a good number of people. > > > (2) If there are no objection to hosting this code here, shall NIO based > > client-side components be developed as a project distinct from > > traditional HttpClient with a separate release cycle, probably even > > starting with the release version 1.0, or shall we develop it as a > > module of HttpClient sharing the same release cycle? > > I vote for a distinct project with its own release cycle -- of course, > I have no clue the amount of work involved with that. My rationale > for wanting a separate cycle is that the httpcore-nio component is > much more tightly tied with httpcore than httpclient-nio would > presumably be tied with httpclient. The whole httpclient stack is > very blocking-based, and very little could could be reused. In my > head, the two are completely different entities. (Of course, if > ultimately we find there is could that can be reused, and that code > moves into a common httpclient module that's shared by httpclient-bio > and httpclient-nio, then maybe it does make sense to share a release > cycle.) > Hi Sam I really hope we manage to re-use at least some of the low level primitives from HttpConn. Anyway, I suggest we start hacking quietly in the sandbox and see how things shape up. Depending on how well (or badly) we fare, we can either pull the plug on the whole thing, promote it to a full-fledged project or fold it into HttpClient. > > (3) Anyone interested in getting involved in the early stages of > > development and helping me define the API and the component architecture > > for the NIO connection manager? > > I'm game, especially as I'll be working on utilizing httpcore-nio for > LimeWire's downloads around the same time. (I'm sidetracked right now > on preparing for a new release, but that should only last a few > weeks.) Step 1, I think, would be to go through the blocking > connection managers and define what it is they're useful for & what > they do, and tweak the ideas around a bit to work in a non-blocking > context. > Cool. Sounds encouraging! Cheers Oleg > Sam > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO based connection manager impl / async HttpClient
--- Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > Folks, > > I would like to start working on a NIO based version > of the connection > manager sometime in the coming days / weeks. A > connection manager > implementation for non-blocking HTTP connections can > be potentially > useful for both Synapse and LimeWire, and probably > other projects as > well. ... I know this is slightly off-topic for the list, but since it is related to non-blocking aspects of data transfer I hope it's ok. I have been working on a non-blocking xml parser (feed data when it becames available, see if new events can be parsed and returned), and was thinking that it would be a good fit for non-blocking data transfer components (or put another way: without non-blocking i/o there aren't many benefits to non-blockin parsing). So, if anyone is interested for this, feel free to email me and I can give more info. -+ Tatu +- Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO based connection manager impl / async HttpClient
> (1) First off, are there any objections to developing an NIO connection > manager within HC? Not from me -- I think it definitely falls within the scope of the project, given that NIO components already exist and seem to be used by a good number of people. > (2) If there are no objection to hosting this code here, shall NIO based > client-side components be developed as a project distinct from > traditional HttpClient with a separate release cycle, probably even > starting with the release version 1.0, or shall we develop it as a > module of HttpClient sharing the same release cycle? I vote for a distinct project with its own release cycle -- of course, I have no clue the amount of work involved with that. My rationale for wanting a separate cycle is that the httpcore-nio component is much more tightly tied with httpcore than httpclient-nio would presumably be tied with httpclient. The whole httpclient stack is very blocking-based, and very little could could be reused. In my head, the two are completely different entities. (Of course, if ultimately we find there is could that can be reused, and that code moves into a common httpclient module that's shared by httpclient-bio and httpclient-nio, then maybe it does make sense to share a release cycle.) > (3) Anyone interested in getting involved in the early stages of > development and helping me define the API and the component architecture > for the NIO connection manager? I'm game, especially as I'll be working on utilizing httpcore-nio for LimeWire's downloads around the same time. (I'm sidetracked right now on preparing for a new release, but that should only last a few weeks.) Step 1, I think, would be to go through the blocking connection managers and define what it is they're useful for & what they do, and tweak the ideas around a bit to work in a non-blocking context. Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
