Mehmet, Cool I just wanted to understand your reasoning which I very much agree with. Mina is nice and tight and keeping it that way complies with KISS. However I think the separation of these classes into separate packages is not a bad idea. That would help cleanup some of the cyclic dependencies in MINA as Trustin suggested.
Regards, Alex On 2/21/07, Mehmet D. AKIN <[EMAIL PROTECTED]> wrote:
Mina is already a tiny package with a lot of power in it, I dont see the point to extract a vital part of it as a seperate jar. Distributing, using and managing a single jar is always better and easier. I know its not a big deal, but to me simpler is better. in short, I am totally agree with Jeroen Brattinga. A seperate automatically generated ByteBuffer.jar is ok as long as it is also in mina. On 2/20/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Without sounding like my 5 year old :), but why not? Could you give more > reasons than just your opinion? > > Alex > > On 2/19/07, Mehmet D. AKIN <[EMAIL PROTECTED]> wrote: > > > > On 1/21/07, Trustin Lee <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > The MINA ByteBuffer classes can be used without MINA for easier > > manipulation > > > of NIO ByteBuffers. For now, they belong to mina-core JAR, but we could > > > split it even further to the two JARs; mina-bytebuffer, mina-core, and > > > mina-transport-nio. By this sepration, we could remove some bad cyclic > > > dependencies between transport implementation and the core API and allow > > > users enjoy the access to the powerful byte buffer manipulation without > > > using MINA. > > > > > > WDYT? > > > > -1 > > > > I dont think mina should be split even further. Maybe they could be > > seperated for external use but Mina core should contain them too. > > >
