It makes sense I think! Would we still keep codec implementations in
subprojects under mina/ (like filter-codec-http)?
I think that each codec should have its own sub-project, with its own
versioning scheme. There is no reason why it should depend on MINA in
any way, except through a dependency.
This is a dangerous approach which will be a real problem when
protocol's codecs will flourish, as you will have difficult time
synchronizing all of them when you will want to release a new MINA version.
We have only one codec (or two including Netty? :) so far and didn't
experience any problem yet.
Should we have to wait until we get hit by a problem to fix it ?
I'd rather wait and see more codecs to
appear before we say that it will be a real problem. It doesn't hurt
anyone. :)
That's not a good position, IMHO. This is likely to become a problem,
but more than that, it is clear that having the HTTP codec with MINA
code is wrong, from the 'separation of concern' POV. MINA is a network
framework, HTTP is a protocol which can be built on top on a framework.
I see no point for HTTP to be part of a network framework.
Codecs should be seen as plugins, and should have there own life, and
own versioning scheme.
Does it make sense to you, guys ?
Then what about other submodules like filter-compression,
integration-*, statemachine and transport-*?
filter-compression, etc are not codecs for which you have existing RFCs.
Http does. That's why it's really different. But anyway, at some point,
yes, those filters might be seen as separated projects.
Should they all be
thought as plugins in the same context? Some components doesn't
change a line when we cut a new release. What makes codecs so
special?
Because they are in no way linked to MINA, whatsoever. They have their
own separate life, and cycle. They make them totally different
components. What if LDAP protocol codec was a part of MINA ? HTTP codec
is exactly the same kind of codec than LDAP codec is, and deserves to be
put in a different project.
That it's under MINA hat is a different question.
I see codecs as submodules that deeply depends on MINA
constructs like other submodules does.
I don't share this vision. It's the way it's implemented atm which make
you think they are part of mina. Again, LDAP codec is not implemented
this way, and it works pretty fine, so far...
A protocol implementation consists of a codec, message flow and
business logic. A codec itself can't do anything at all. Codecs are
very low-level component - you need something more on top of it to
comply with the protocol, and that's why I think it should be a
submodule of MINA distribution.
A codec does a lot : it encodes and decode the messages. And I don't
think that :
if (query != null && query.length() > 0) {
buf.put((byte) '?');
buf.putString(query, asciiEncoder);
}
buf.putString(" HTTP/1.1", asciiEncoder);
as nothing to do in MINA. It's so HTTP-ish...
Those only who understand how to use
MINA API can use the codec.
That does not imply codecs should be part of MINA.
What's the use of providing it as a
separate distribution?
I think I already replied to this question : because protocol's cycles
are different from MINA cycle. And a codec should be linked to a version
of MINA, not the opposite. It should be possible to modify a codec
without changing the MINA version used, when the opposite is clearly
more complex. What will we do if we change MINA and we have to change N
versions of codecs just because MINA's API has been changed ? You have
no idea of the impact of such modifications can have on projects which
uses the codecs, when the codec's implementors know what they are doing
when switching the underlying MINA layer. Remember that it's what we are
doing for ADS for years right now : we decide when and why we should
switch from MINA x to MINA y.
What's more important IMHO is whether we are
going to provide the codec as a separate JAR file or not, and we are
doing so already.
It's not only about the jar, it's about the version.
HTTP != MINA, as LDAP != MINA. It would hurt to depend on MINA to be
able to release ADS, and it would hurt AsyncWeb to depend on MINA to
release a version too. Working with snapshots is not the way to go, and
it is the clear path we are taking if we keep codecs within mina. That's
why I do think that they deserves to be considered as sub-projects.
And it's not complex at all, as the codec is already a separated
project. It's just a question to separate it from MINA trunk.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
