You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2007/01/21 00:16:59 UTC

Separating MINA ByteBuffer classes into a new JAR package.

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?

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Alex Karasulu <ak...@apache.org>.
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 <md...@gmail.com> 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 <ak...@apache.org> 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 <md...@gmail.com> wrote:
> > >
> > > On 1/21/07, Trustin Lee <tr...@gmail.com> 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.
> > >
> >
>

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by "Mehmet D. AKIN" <md...@gmail.com>.
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 <ak...@apache.org> 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 <md...@gmail.com> wrote:
> >
> > On 1/21/07, Trustin Lee <tr...@gmail.com> 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.
> >
>

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Jeroen Brattinga <je...@gmail.com>.
It should be as simple as possible to use Mina. Splitting basic
functionality into separate packages (e.g. core + ByteBuffer) is IMO not the
way to go. I can understand the need for a separate ByteBuffer package, but
I don't see why that should affect every Mina user.

(yes, it's almost splitting hairs ... but I still think it's an important
decision :-)
-- 
Jeroen Brattinga


2007/2/20, Alex Karasulu <ak...@apache.org>:
>
> Without sounding like my 5 year old :), but why not?  Could you give more
> reasons than just your opinion?
>

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Alex Karasulu <ak...@apache.org>.
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 <md...@gmail.com> wrote:
>
> On 1/21/07, Trustin Lee <tr...@gmail.com> 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.
>

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by "Mehmet D. AKIN" <md...@gmail.com>.
On 1/21/07, Trustin Lee <tr...@gmail.com> 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.

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by peter royal <pr...@apache.org>.
On Jan 21, 2007, at 4:02 PM, Trustin Lee wrote:
> On 1/21/07, Jeroen Brattinga <je...@gmail.com> wrote:
>>
>> I meant that the mina-core jar keeps the ByteBuffer  
>> implementation, and
>> -for
>> those that want only to use the Mina ByteBuffer- a separate  
>> ByteBuffer
>> jar.
>> But it's not needed for the Mina framework.
>
>
> It's also a good idea, though I'm not sure Maven can do it for us.
>
> By the way, please note this is not a vote.  :)

I agree with Jeroen.. Supplying a jar with just the ByteBuffer code  
is fine, for people that just want that and not the rest of MINA, but  
the code should also remain in mina-core.jar as well.
-pete


-- 
proyal@apache.org - http://fotap.org/~osi




Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Trustin Lee <tr...@gmail.com>.
On 1/21/07, Jeroen Brattinga <je...@gmail.com> wrote:
>
> I meant that the mina-core jar keeps the ByteBuffer implementation, and
> -for
> those that want only to use the Mina ByteBuffer- a separate ByteBuffer
> jar.
> But it's not needed for the Mina framework.


It's also a good idea, though I'm not sure Maven can do it for us.

By the way, please note this is not a vote.  :)

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Jeroen Brattinga <je...@gmail.com>.
I meant that the mina-core jar keeps the ByteBuffer implementation, and -for
those that want only to use the Mina ByteBuffer- a separate ByteBuffer jar.
But it's not needed for the Mina framework.

-- 
Jeroen Brattinga

2007/1/21, Trustin Lee <tr...@gmail.com>:
>
> On 1/21/07, Jeroen Brattinga <je...@gmail.com> wrote:
> >
> > -1
> >
> > I don't really see the point in an extra jar for the ByteBuffer. If you
> > want
> > users to be able to use the powerful Mina ByteBuffer, why not release an
> > independent jar just for this goal?
>
>
> What do you mean by 'independent jar'?  Is it something different from
> what
> I said?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6
>
>

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Trustin Lee <tr...@gmail.com>.
On 1/21/07, Jeroen Brattinga <je...@gmail.com> wrote:
>
> -1
>
> I don't really see the point in an extra jar for the ByteBuffer. If you
> want
> users to be able to use the powerful Mina ByteBuffer, why not release an
> independent jar just for this goal?


What do you mean by 'independent jar'?  Is it something different from what
I said?

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Jeroen Brattinga <je...@gmail.com>.
-1

I don't really see the point in an extra jar for the ByteBuffer. If you want
users to be able to use the powerful Mina ByteBuffer, why not release an
independent jar just for this goal?

-- 
Jeroen Brattinga


2007/1/21, Hanson Char <ha...@gmail.com>:
>
> +1
>
> On 1/20/07, Trustin Lee <tr...@gmail.com> 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?
> >
> > Trustin
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > --
> > PGP key fingerprints:
> > * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
> > * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6
> >
> >
>
>

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Hanson Char <ha...@gmail.com>.
+1

On 1/20/07, Trustin Lee <tr...@gmail.com> 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?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6
>
>

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Mark Webb <el...@gmail.com>.
splitting the ByteBuffer code out into a separate jar file sounds good to
me.  I know of some programs that I am working with that do not perform any
network I/O could still make good use of a small, stand-alone jar file
without bringing along the MINA I/O classes

+1

On 2/16/07, John E. Conlon <jc...@verticon.com> wrote:
>
> If we split the projects up to additional jars, can we do it so we do
> not create split packages?  (Packages that exist in more than jar.)
> John
>
> Mike Heath wrote:
> > This would provide a very convenient way to use the MINA ByteBuffer in
> > AIO without having to depend on all of MINA core.  I like this idea a
> > lot.
> >
> > -Mike
> >
> > On 1/20/07, Trustin Lee <tr...@gmail.com> 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?
> >>
> >> Trustin
> >> --
> >> what we call human nature is actually human habit
> >> --
> >> http://gleamynode.net/
> >> --
> >> PGP key fingerprints:
> >> * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
> >> * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6
> >>
> >
> >
>
>


-- 
..Cheers
Mark

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by "John E. Conlon" <jc...@verticon.com>.
If we split the projects up to additional jars, can we do it so we do 
not create split packages?  (Packages that exist in more than jar.)
John

Mike Heath wrote:
> This would provide a very convenient way to use the MINA ByteBuffer in
> AIO without having to depend on all of MINA core.  I like this idea a
> lot.
>
> -Mike
>
> On 1/20/07, Trustin Lee <tr...@gmail.com> 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?
>>
>> Trustin
>> -- 
>> what we call human nature is actually human habit
>> -- 
>> http://gleamynode.net/
>> -- 
>> PGP key fingerprints:
>> * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
>> * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6
>>
>
>


Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Mike Heath <mh...@apache.org>.
This would provide a very convenient way to use the MINA ByteBuffer in
AIO without having to depend on all of MINA core.  I like this idea a
lot.

-Mike

On 1/20/07, Trustin Lee <tr...@gmail.com> 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?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6
>

Re: Separating MINA ByteBuffer classes into a new JAR package.

Posted by Vinod Panicker <vi...@gmail.com>.
On 1/21/07, Trustin Lee <tr...@gmail.com> 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