Trustin Lee wrote:
I agree with some points Emmanuel made, but it doesn't mean that I
totally agree with him for all points he made such as versioning,
similarity between LDAP and HTTP, and HTTP-ish codec.
However, I don't want to drag this thread spending each other's energy
unnecessarily replying to every sentence.
The thing is that the point we don't agree on are to be clarified,
because they are important. May be another thread would be good.
What we really want to see
is the best scalable directory layout that will last for another
century. So, let me try again to restructure the directory layout
from most reasonable and orthogonal point of view. ;)
What a usual protocol codec (including HTTP codec) currently depends on is:
* MINA IoBuffer
* MINA IoSession (to access properties, not to perform a real I/O operation)
* MINA codec infra
IIRC, we discussed about providing a separate artifact for buffer
utilities and codec infrastructure, but users didn't like to have
extra JARs in their classpath. From this point of view, MINA is
actually a mix of codec infra and network framework. So... we have
two different things in one core, and that's the root cause of all
these problems.
Therefore, it seems like there's some chasm between what's most
reasonable and what users feel most comfortable with. I'm not sure
what will be the best choice for us. Anyways, the most reasonable
layout will look like this then:
/ - core - codec-framework (name tbd, IoBuffer + existing codec infra)
- mina (pure network framework, shall we rename? :)
well, "mina" is ok as a name for the core.
- codec - HTTP codec (all depends on codec-framework only)
- FTP codec
- SMTP codec
- frontend - ahc (name tbd, my preference - Superluminal)
"superluminal" is a little bit too long, and considering that nothing
can exceed light speed ... Do we have to find acronym for every project?
Is this just me ? Is everyone confortable with the idea of using an
HashMap to remember the relation between a obscure acronym and a project
? (cayenne, felix, james, lenya, geronimo, gump, santuario, shale,
tiles...)
- ftpserver (name tbd if Niklas wants something cool :D)
- asyncweb (if Alex wants to work on it)
This sounds ok to me, assuming that each codec has its own version and
jar. There is nothing wrong to have a codec top level pom.xml, pointing
on each codec project, as soon as one can compile and package a specific
codec easily.
It's somewhat complicated, but it's most scalable layout IMHO. Does
it look much better guys?
It does.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
