(Constructive?) criticism of Grizzly

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

(Constructive?) criticism of Grizzly

cowwoc
Hi,

I am new to both Grizzly and Mina. I just wanted to put out my first impressions in the hopes that it will help you improve the project.

I read about Grizzly here: https://grizzly.dev.java.net/presentations/FISL-2007.pdf
I read about Mina here: http://people.apache.org/~proyal/MINA%20AC%20EU%202007.pdf

1) I find the Mina presentation to be of much higher quality. It was much easier to understand and got directly to the point.

2) I found the class names in Mina much easier to understand. Consider IoSession, IoProcessor, IoFilter, IoHandler (for Mina) versus ProtocolChain, SelectorHandler, SelectionKeyHandler, InstanceHandler (for Grizzly).

In all honestly, when I approach a new API I don't care whether it uses Selector under the hood or not. You should be using layman terminology that is easy to understand like Mina does. I can guess what Mina classes do without reading their documentation purely by their names whereas in order to understand Grizzly I'd have to both read your documentation as well as understand NIO terminology. Please, keep your target audience in mind and use simpler names :)

So in summary I am suggesting you do two things:

1) Write up comprehensive ***easy-to-read*** documentation for Grizzly. What currently exists on the website is not enough.

2) Simplify the API terminology as much as possible.

If I am given a choice between Mina and Grizzly and I know that Grizzly might be 30% faster than Mina I am still more likely to use Mina because it is easier to get started with and it's probably "good enough" for my use-case. Just my 2 cents :)

Gili
Reply | Threaded
Open this post in threaded view
|

Re: (Constructive?) criticism of Grizzly

cowwoc
Their Tutorials section is also very good: http://mina.apache.org/documentation.html

compared to https://grizzly.dev.java.net/ that doesn't seem to contain any tutorials. I'm sure Grizzly is great but there is no way for me to find out without some better documentation (and presentation).

Gili
Reply | Threaded
Open this post in threaded view
|

Re: (Constructive?) criticism of Grizzly

cowwoc
I have more suggestions for improvements but I think everyone's time would be better served if you guys just watched this video: http://www.infoq.com/presentations/effective-api-design

It is a brilliant presentation!
Reply | Threaded
Open this post in threaded view
|

Re: (Constructive?) criticism of Grizzly

charlie hunt-3
In reply to this post by cowwoc
Hi Gili,

I have read all 3 of your e-mails and really appreciate your feedback!

Would you mind filing a couple enhancements in Grizzly's issue tracker
for tutorials & class names along filing bug(s) for the API
documentation?  Please be as specific as possible.  Also feel free to
copy your 3 e-mails into the issues too.

I am not trying to make excuses in what I'm gonna say here. :-/

As you saw in the Grizzly FISL presentation, Grizzly's evolution is
quite different from Mina.   Grizzly went open source earlier this
year.  IIRC, Mina has been open source for over 2 years.  We know
tutorials, how to's and general documentation is something we need to
improve.  You may have also seen on the front page of Grizzly, "Get a
Grizzly t-shirt! Here is how
<http://blogs.sun.com/charliebrown/entry/who_wants_a_t_shirt>. "?  This
is an effort to help with documentation and tutorials.

In comparing Mina to Grizzly, my claim is that Mina's major focus is on
a general purpose NIO framework. In contrast, Grizzly's major focus is
on performance.

Does this mean the API or class names used in Grizzly are for
performance reason, of course not. ;-)  The class names and APIs chosen
are more of an artifact of Grizzly's evolution having initially started
as an non-blocking NIO based Tomcat HTTP Connector for the then Sun Java
System Application Server Platform Edition.

Additionally, since there were many requests getting Grizzly released as
open source we likely sacrificed some API documentation as a result.

Again, thanks for the feedback!

charlie ...

cowwoc wrote:

> Hi,
>
> I am new to both Grizzly and Mina. I just wanted to put out my first
> impressions in the hopes that it will help you improve the project.
>
> I read about Grizzly here:
> https://grizzly.dev.java.net/presentations/FISL-2007.pdf
> I read about Mina here:
> http://people.apache.org/~proyal/MINA%20AC%20EU%202007.pdf
>
> 1) I find the Mina presentation to be of much higher quality. It was much
> easier to understand and got directly to the point.
>
> 2) I found the class names in Mina much easier to understand. Consider
> IoSession, IoProcessor, IoFilter, IoHandler (for Mina) versus ProtocolChain,
> SelectorHandler, SelectionKeyHandler, InstanceHandler (for Grizzly).
>
> In all honestly, when I approach a new API I don't care whether it uses
> Selector under the hood or not. You should be using layman terminology that
> is easy to understand like Mina does. I can guess what Mina classes do
> without reading their documentation purely by their names whereas in order
> to understand Grizzly I'd have to both read your documentation as well as
> understand NIO terminology. Please, keep your target audience in mind and
> use simpler names :)
>
> So in summary I am suggesting you do two things:
>
> 1) Write up comprehensive ***easy-to-read*** documentation for Grizzly. What
> currently exists on the website is not enough.
>
> 2) Simplify the API terminology as much as possible.
>
> If I am given a choice between Mina and Grizzly and I know that Grizzly
> might be 30% faster than Mina I am still more likely to use Mina because it
> is easier to get started with and it's probably "good enough" for my
> use-case. Just my 2 cents :)
>
> Gili
>  


--

Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)

<http://java.sun.com/docs/performance/>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]