Hi,
Nice to U2:)
Dear Charlie, I do not mean that you said which bad or which good.
If I let you feel I meaned that, I say sorry.
I know someone like to do that, and I know someone will not do that, like
people in the thread.
OK, let it be.
Jarcand bring a great idea.
About Context, just peronallys, I think where or not expose too more thing
to client.
Maybe separating it two parts not bad, one for client, one internal
implementation.
Now I do a context interface:
interface Context {
void read();
void close();
void write(Object message);
void blockingWrite(Object message); //or write(Object message, boolean
blocking);
InetSocketAddress getRemoteAddress();
InetSocketAddress getLocalAddress();
}
read, close, write can replace KeyRegistrationState related operation.
Not only for client, also for internal, it's more clear.
Another aspect, I not clear why connect operation in context.
I think if separate connect to other place it should be, context will be
more clear and great.
Again, I not capture all grizzly thought, I just state my pool understand.
And again, sorry for my damn english.
Regards,
2007/6/16, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com>:
>
> Hi,
>
> once 1.5.2 is out the door, It might be a good idea to start a new sub
> module that contains high level interface (like context.write(String))
> and evangelize that such API might (or might not) gives the same
> performance as the low level one. I would think this is a good extension
> , and more important, a very good way to get a free t-shirt if people
> wants to collaborate :-)
>
> A+
>
> -- Jeanfrancois
>
> charlie hunt wrote:
> > The point I was making is that Grizzly's primary focus is on performance
> > & scalability where performance is throughput & responsiveness
> > performance and scalability is its ability to take on more load and
> > maintain the performance throughput and responsiveness.
> >
> > I did not say or claim higher level interfaces is a bad thing. It
> > depends on the application being developed as to whether performance &
> > scalability take preference over the ability to program at a higher
> > level interface, (which Grizzly will slower migrate that direction as it
> > evolves, but it will not sacrifice performance in migrating to a general
> > purpose framework).
> >
> > Let me also make clear that I have not said mina is a bad framework.
> > Quite frankly it is a good framework. I'm only claiming that there's a
> > different focus on priorities with mina and grizzly. My claim is that
> > mina is a good general purpose framework which lesser emphasis on
> > performance. Grizzly primary focus is performance with (at the moment)
> > lesser emphasis on being a general purpose framework.
> >
> > Hope that makes sense.
> >
> > Btw, thanks for sharing your experience in developing your application
> > with Grizzly. We appreciate any feedback you can give us.
> >
> > thanks,
> >
> > charlie ...
> >
> > 向秦贤 wrote:
> >> Hi Hunt,
> >> I must admit I not capture all of your means on the last paragraph.
> >> And I must say sooooooorry for my pool english again.
> >> Performance, hmm, In my eyes, there are many kind of performance.
> >> I do a joke, it's a performance. You do speeching, it's a performance
> >> too.
> >> Java with a vm do execution, it's a performance tooooo.
> >> 100m dashing, it's one person performance.
> >> tug-of-war, it's people's performance.
> >> From above, we can get a view:
> >> Performance not just for only performance, but for happiness, and for
> >> world, and for romance.
> >>
> >> I have checked out J12007 grizzly report in which there is a
> >> performance comparasion between
> >> grizzly and mina. both 2 point grizzly higher than mina, but not more
> >> higher.
> >> And from comprarasion between grizzly and c style server, grizzly can
> >> do great performance.
> >>
> >> So, I think that high level should not a bad thing. We can just take a
> >> talk on Java.
> >> In my heart, Java more higher than cX. but why grizzly can do a higher
> >> than cX-Servers.
> >> It's a evidence. that it is. So why not grizzly do higher level.
> >> From this point extend to Java language, Java can do more higher.
> >>
> >> There is a base in it, just like china say, more people picking more
> >> woods, more flaming more blaze.
> >> It do a metaphor, grizzly do more higher, more people do more
> >> participating, grizzly do more great. And Java do this way now. is it?
> >> or isn't it?
> >>
> >> Ok, soooorry for my pool english again.
> >>
> >> BTW, Jacrand, I'm waint for you check out grizzly I about write
> >> selector code comments from me.
> >> You remember it? :)
> >> Ooops, if not, right, please jump to
> >>
> http://weblogs.java.net/blog/jfarcand/archive/2006/05/tricks_and_tips_1.html
> >>
> >> Wish someone do speaking china.:)
> >> Happy to hear you.
> >>
> >> Regards,
> >>
> >> 2007/6/16, charlie hunt <charlie.hunt_at_sun.com
> >> <mailto:charlie.hunt_at_sun.com>>:
> >>
> >> Some evidence of what I have been claiming as a differentiator
> between
> >> mina and grizzly which is grizzly's emphasis is on performance &
> >> scalability where mina's emphasis is on a general purpose
> framework.
> >>
> >> I make this claim based the comment, "grizzly just provide low
> >> level api
> >> for developer, proactor do it too, only mina give higher level api
> >> for
> >> developer".
> >>
> >> I'd claim Grizzly is being proactive to not produce an API or set
> of
> >> APIs that might inhibit performance and scalability. If we do, I'd
> >> expect that we'd deprecate them in a later release should one
> >> manage to
> >> creep in.
> >>
> >> charlie ...
> >>
> >> Jeanfrancois Arcand wrote:
> >> > Interesting....
> >> >
> >> > -------- Original Message --------
> >> > Subject: Number of class, Maybe and How?
> >> > Date: Fri, 15 Jun 2007 11:39:14 +0800
> >> > From: 向秦贤 <fyaoxy_at_gmail.com <mailto:fyaoxy_at_gmail.com>>
> >> > Reply-To: dev_at_mina.apache.org <mailto:dev_at_mina.apache.org>
> >> > To: dev_at_mina.apache.org <mailto:dev_at_mina.apache.org>
> >> >
> >> > Sirs,
> >> > I tried mina with FTP client. and planing a FTP server, maybe
> >> rush into
> >> > apache ftpserver by using mina.
> >> > There is an interesting comparation between mina with grizzly,
> >> proactor, and
> >> > aio.
> >> >
> >> > with mina 1.1, I do a ftp client, need mina supported class java
> >> file about
> >> > 83.
> >> > with grizzly, about 25.
> >> > with proactor about 20.
> >> > inner class not included, I just count java file.
> >> > I don't know the number if mean something.and if it is, but How
> >> to do in
> >> > future?
> >> >
> >> > Besides coconut (not competed), grizzly just provide low level
> >> api for
> >> > developer,
> >> > proactor do it too, only mina give higher level api for
> developer.
> >> > I like this point. and In my personal view, I feel it is
> >> possible that
> >> > removing some operation from session context (in mina aka
> >> iosession).
> >> >
> >> > Hope hear you. And Sooooooooooorry for my pool english writing.
> >> >
> >> > Regards,
> >> >
> >> >
> >>
> >> --
> >>
> >> Charlie Hunt
> >> Java Performance Engineer
> >> 630.285.7708 x47708 (Internal)
> >>
> >> <http://java.sun.com/docs/performance/
> >> <http://java.sun.com/docs/performance/>>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> >> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
> >> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >> <mailto:dev-help_at_grizzly.dev.java.net>
> >>
> >>
> >>
> >>
> >> --
> >> 向秦贤
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
--
向秦贤