Is it ready? You're only at M1. What are the next milestones planned
before you hit beta?
Regards,
Alan
On Feb 9, 2008, at 3:56 PM, Maarten Bosteels wrote:
Sticking to MINA 2.0 overall will be in the best interest of the
community
I couldn't agree more. I really see no reason to stick
On Feb 9, 2008, at 3:22 PM, Alan D. Cabrera wrote:
On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote:
4) Future objects for any blocking operation
I was thinking that we could have a Future object that implements an
AHC callback interface. This would keep the client simple. Those
I think that this bit can be, and is, handled with URLs. I don't see
the advantage of adding complexity to the metaphor and, hence, the API.
This isn't a metaphor, it's an API. Using a metaphor to help conceptualize
what you're trying to accomplish can be helpful, but there's no point in
Alan D. Cabrera wrote:
On Feb 9, 2008, at 3:22 PM, Alan D. Cabrera wrote:
On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote:
4) Future objects for any blocking operation
I was thinking that we could have a Future object that implements an
AHC callback interface. This would keep the
David M. Lloyd wrote:
The limitation on what would be allowed on a connection URI is the reason
that I suggested earlier that the API could accept discrete scheme,
hostname,
and port parts - since the rest of the URI is not useful anyway. But since
either method satisfies the requirements
Tuure Laurinolli wrote:
Of course, the casual user probably doesn't care about connection
pooling, and possibly not even about pipelining and keep-alive, he just
wants a component that takes an HttpRequest, does some magic and gets an
HttpResponse back to the callback he gave to the component.
David M. Lloyd wrote:
Yes, this is my thinking as well - the casual user wants a simplified API,
while the advanced user wants a more detailed interface.
Certainly no reason not to offer both capabilities ;-)
Jeff
- DML
Alan D. Cabrera wrote:
I see and take your point. It is six of one and half a dozen of
another. What I'm confused about is why we need to initially specify
anything outside of the actual request. What problem are we trying to
solve? Maybe I'm misunderstanding what you are espousing so let
On Feb 10, 2008, at 10:35 AM, David M. Lloyd wrote:
Alan D. Cabrera wrote:
On Feb 9, 2008, at 3:22 PM, Alan D. Cabrera wrote:
On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote:
4) Future objects for any blocking operation
I was thinking that we could have a Future object that implements
Hello,
On Feb 10, 2008 5:28 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote:
Is it ready? You're only at M1. What are the next milestones planned
before you hit beta?
The version numbering scheme is described at the bottom of
http://mina.apache.org/downloads.html [1]
IMO we should have
On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote:
Hello,
On Feb 10, 2008 5:28 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote:
Is it ready? You're only at M1. What are the next milestones
planned
before you hit beta?
The version numbering scheme is described at the bottom of
On Feb 10, 2008, at 10:05 AM, David M. Lloyd wrote:
I think that this bit can be, and is, handled with URLs. I don't
see the advantage of adding complexity to the metaphor and, hence,
the API.
This isn't a metaphor, it's an API. Using a metaphor to help
conceptualize
what you're
The way it stands now, AHC takes a javax.net.ssl.SSLContext object as a way
to configure/handle SSL. While this provides a maximum flexibility (one can
create any type of configuration and trust/key management as he/she sees
fit), perhaps one could use easier steps of providing more standard
That is a great idea. It should not be hard to add these events...
Regards,
Sangjin
On Feb 9, 2008 1:49 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote:
What we have looks pretty neat. Here is some information that I would
love to get my hands on:
- first byte - not really REQUEST_STARTED
-
Going back on some of the points here...
On Jan 29, 2008 2:25 PM, Mike Heath [EMAIL PROTECTED] wrote:
Connecting - Connecting is done as a blocking operation. In Jeff
Geneder's AHC branch in the Geronimo sandbox, thread pools are being
used for asynchronous connecting. This is unfortunate
I can see cases where one might need a very short connect timeout. If your
use case requires a very low fault tolerance and if you would rather fail
calls than waiting for any longer than is necessary, then 1 second might not
be an adequate minimum value. The characteristic would be a high-load
Until 2.0 GA we should leave the trunk as is. When we go to GA after some
number of milestones then we can create the 2.0 branch which will only
include bug fixes. Right now the bleeding edge is the trunk. This is where
all new features and API changes occur.
I think we can do milestone
+1
This was well put Sangjin. After reading this I realized that may
deployments of AHC will have similar needs: sub-second timeouts are
critical.
Alex
On Feb 10, 2008 7:10 PM, Sangjin Lee [EMAIL PROTECTED] wrote:
I can see cases where one might need a very short connect timeout. If
your
2008-02-10 (일), 00:56 +0100, Maarten Bosteels 쓰시길:
Sticking to MINA 2.0 overall will be in the best interest of the community
I couldn't agree more. I really see no reason to stick with 1.x
In fact, I think we should 'release' MINA-2.0-M1 asap.
Yeah, go MINA! :)
Trustin
--
what we call
First off, I agree with what's under consensus so far in this thread.
Great to see more people get involved! :)
2008-02-09 (토), 17:01 -0800, Alan D. Cabrera 쓰시길:
On Feb 9, 2008, at 3:56 PM, Mike Heath wrote:
Alan D. Cabrera wrote:
snip
That's a good thought. The reason that the URL
Great. Thanks, Alan!
Cheers,
Trustin
2008-02-09 (토), 17:58 -0800, Alan D. Cabrera 쓰시길:
Here you go:
http://cwiki.apache.org/confluence/display/AWEB/Index
Regards,
Alan
On Feb 9, 2008, at 5:45 PM, Alex Karasulu wrote:
On Feb 9, 2008 8:32 PM, 이희승
(Trustin Lee) [EMAIL
On Feb 11, 2008 1:28 AM, Mike Heath [EMAIL PROTECTED] wrote:
Jeff Genender wrote:
David M. Lloyd wrote:
Yes, this is my thinking as well - the casual user wants a simplified
API,
while the advanced user wants a more detailed interface.
Certainly no reason not to offer both
I would have to give Sangjin's arguments a +0. I think he makes some
good points but I don't think I would say that support sub-second
timeouts is _critical_ until people start asking for it.
Load balancing is a case where connect timeouts would be important and
all of the load balancers I've
The new logging features in SLF4J and removing IoSessionLogger were what
was holding up an M1 release. Where do we stand on the logging front
right now?
-Mike
Maarten Bosteels wrote:
On Feb 10, 2008 9:05 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote:
On Feb 10, 2008, at 11:35 AM, Maarten
Jeff Genender wrote:
David M. Lloyd wrote:
Yes, this is my thinking as well - the casual user wants a simplified API,
while the advanced user wants a more detailed interface.
Certainly no reason not to offer both capabilities ;-)
I totally agree. I think we should offer a very simple
Most of the statements I made were referring to the AsyncWeb client code
and not the latest AHC code that came over from Geronimo. There is a
huge difference here and I think that's what led to a lot of the
confusion over the statements I made.
-Mike
Sangjin Lee wrote:
Going back on some of
David M. Lloyd wrote:
Alan D. Cabrera wrote:
snip
So, I was thinking that you would send requests like so:
ahc.send(url, listener);
This is a departure from the rest of MINA though, in which the idiom
is more like this:
ahc.send(request).setListener(listener); // does not block
To
27 matches
Mail list logo
