On Thu, 19 Jun 2008 14:15:27 -0400
Jeanfrancois Arcand <[EMAIL PROTECTED]> wrote:
> Salut,
> 
Salut, 
I'll try to make a message shorter than two politician wannabees ;)

Bienvenue ! comments inline.

> after weeks of delay(ss), I'm back :-) Last time we discussed
> possible collaboration between the two frameworks. I've proposed the
> idea to my colleagues and as expected, every body were on the
> defense :-) The Sun-Apache collaboration hasn't always working really
> well over the last couple of years, and I suspect this didn't
> helped ;-). Let's no just discuss that here....
> 
> So, one of the proposition was to merge the two projects. I don't
> think that one can happens :-) And the license isn't yet matching,
> although I'm trying to have Apache 2 license support in Grizzly
> (actually I'm not trying, it's one task for our new Grizzly project
> lead :-)).

Would be very interesting because we could share code directly, but
it's Sun money and workforce, so it's up to Sun.

> 
> So my little proposal is the following. I would like to learn MINA
> and be involved as an individual contributor. One thing that I would
> like to explore is have MINA implemented on top of Grizzly, similar
> to MINA running on top of APR. What the MINA community will gain with
> that? Little except the feedback I will give....but also it will
> means that application that wants to use Grizzly low level API can
> combine them with MINA high level API.

I know it's a bit early if you didn't dug much in mina code. But do
you think about porting the mina codec facilities to grizzly (mean no
filter) or implements a mina transport using grizzly (like nio, apr) ?

> 
> Maybe nobody will want to do that, but at least it will gives me a 
> chance to learn MINA and comes with comments. It may eventually
> brings the two community together and share on the low level works
> (directly or just the experience). Maybe not. Still I think that
> starting small cannot hurt any community. I will for sure gives
> feedback on performance, although we might discover than the current
> version of MINA is faster than Grizzly (naaa maybe :-)).

Or perhaps it'll bridge the communities on the high level topic
(codec/parser implementations).

> 
> What peoples thinks? In any case, I will start looking at the design, 
> something I've refrain myself before (maybe I should have looked, as 
> peoples always tell me it quite trivial to write MINA applications!)).
> 

For have tested the two, I think it's much easier to do a protocol
codec using mina than grizzly but it's perhaps simply because I'm using
the first one since the beginning :) 
Looking at grizzly 2.0 roadmap, improvement are planned on the high
level API. I think we can find convergence on this topic too.

> A+
> 
> -- Jeanfrancois
Bonne nuit,
Julien

Attachment: signature.asc
Description: PGP signature

Reply via email to