Re: doubt Mina
My point :) is that introducing a visitor interface that depends on all
transport modules doesn't sound good to me. If we are going to do that,
the visitor interface will have to be provided as a separate module that
depends on all other transport modules to avoid a cyclic dependency. We
had a similar problem in TransportType in MINA 1.x related with cyclic
dependency.
2008-02-16 (토), 00:21 -0500, Adam Fisk 쓰시길:
Hmmnn...I don't think so. As far as I can tell, he's talking about
adding more types to a future MINA release. That would mean adding a
method to each new type -- hardly a high cost given the return. If
you want to make it possible for users to add types, you could simply
have an visitGenericType method that would be no worse than the
current situation, but it doesn't seem like users adding their own
types would ever be a common use case.
-Adam
On Feb 14, 2008 8:53 AM, David M. Lloyd [EMAIL PROTECTED] wrote:
I believe that Trustin's point is that the visitor pattern is only
effective if you know all the visitable types ahead of time. It's quite
difficult for a user to wedge in their own type after the fact - they
would have to modify the visitor interface for each new transport type
they add.
- DML
Adam Fisk wrote:
I actually think that's exactly why the visitor pattern is nice -- the
more transports you have, the better it gets because you can elegantly
deal with the additional types rather than resorting to instansofs.
The double-dispatch method calling is also a bigger performance boost
the more types you have (as opposed to more else ifs with the
instanceof approach).
A visitor itself can also do all sorts of things other than just
identify the type.
That said, it's really a cosmetic difference either way and barely
worth the discussion -- your time is certainly better spent elsewhere!
-Adam
On Feb 13, 2008 11:58 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
Re: doubt Mina
Hmmnn...I don't think so. As far as I can tell, he's talking about
adding more types to a future MINA release. That would mean adding a
method to each new type -- hardly a high cost given the return. If
you want to make it possible for users to add types, you could simply
have an visitGenericType method that would be no worse than the
current situation, but it doesn't seem like users adding their own
types would ever be a common use case.
-Adam
On Feb 14, 2008 8:53 AM, David M. Lloyd [EMAIL PROTECTED] wrote:
I believe that Trustin's point is that the visitor pattern is only
effective if you know all the visitable types ahead of time. It's quite
difficult for a user to wedge in their own type after the fact - they
would have to modify the visitor interface for each new transport type
they add.
- DML
Adam Fisk wrote:
I actually think that's exactly why the visitor pattern is nice -- the
more transports you have, the better it gets because you can elegantly
deal with the additional types rather than resorting to instansofs.
The double-dispatch method calling is also a bigger performance boost
the more types you have (as opposed to more else ifs with the
instanceof approach).
A visitor itself can also do all sorts of things other than just
identify the type.
That said, it's really a cosmetic difference either way and barely
worth the discussion -- your time is certainly better spent elsewhere!
-Adam
On Feb 13, 2008 11:58 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
http://www.littleshoot.org
Open Source, Open Standards, Open Data
Re: doubt Mina
I believe that Trustin's point is that the visitor pattern is only
effective if you know all the visitable types ahead of time. It's quite
difficult for a user to wedge in their own type after the fact - they
would have to modify the visitor interface for each new transport type
they add.
- DML
Adam Fisk wrote:
I actually think that's exactly why the visitor pattern is nice -- the
more transports you have, the better it gets because you can elegantly
deal with the additional types rather than resorting to instansofs.
The double-dispatch method calling is also a bigger performance boost
the more types you have (as opposed to more else ifs with the
instanceof approach).
A visitor itself can also do all sorts of things other than just
identify the type.
That said, it's really a cosmetic difference either way and barely
worth the discussion -- your time is certainly better spent elsewhere!
-Adam
On Feb 13, 2008 11:58 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: doubt Mina
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
http://www.littleshoot.org
Open Source, Open Standards, Open Data
Re: doubt Mina
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
Re: doubt Mina
to example echoserver, how to make this test:
open 2 conection and send message simultaneous? someone did this?
I want to check the performance of the example echoserver.
some tips?
thanks
On 2/13/08, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
Brenno Hayden F. Dantas
Re: doubt Mina
FYI...if you are going to do this...you are gonna have to tweak your IP
stack to be able to handle that many open sockets.
Jeff
[EMAIL PROTECTED] wrote:
to example echoserver, how to make this test:
open 2 conection and send message simultaneous? someone did this?
I want to check the performance of the example echoserver.
some tips?
thanks
On 2/13/08, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: doubt Mina
How to do I do this?
On 2/13/08, Jeff Genender [EMAIL PROTECTED] wrote:
FYI...if you are going to do this...you are gonna have to tweak your IP
stack to be able to handle that many open sockets.
Jeff
[EMAIL PROTECTED] wrote:
to example echoserver, how to make this test:
open 2 conection and send message simultaneous? someone did this?
I want to check the performance of the example echoserver.
some tips?
thanks
On 2/13/08, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
Brenno Hayden F. Dantas
Re: doubt Mina
I actually think that's exactly why the visitor pattern is nice -- the
more transports you have, the better it gets because you can elegantly
deal with the additional types rather than resorting to instansofs.
The double-dispatch method calling is also a bigger performance boost
the more types you have (as opposed to more else ifs with the
instanceof approach).
A visitor itself can also do all sorts of things other than just
identify the type.
That said, it's really a cosmetic difference either way and barely
worth the discussion -- your time is certainly better spent elsewhere!
-Adam
On Feb 13, 2008 11:58 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
http://www.littleshoot.org
Open Source, Open Standards, Open Data
Re: doubt Mina
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길: Hello , i have same doubt.. - How can I tell if the connection is udp or tcp? In 1.x, you can use IoSession.getTransportType(). In 2.x, you can simply use 'instanceof SocketSession' or 'instanceof DatagramSession'. -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
doubt Mina
Hello , i have same doubt.. - How can I tell if the connection is udp or tcp? - The framework supports 50.000 connections simultaneous and exchange data? What was the most you succeeded? Greetings Brenno Hayden F. Dantas
