2007/5/20, Alwyn Schoeman <[EMAIL PROTECTED]>:
I agree with mat-29.
In order for DemuxingProtocolCodecFactory to call a specific Decoder or
Encoder, it will need to know what the type of the message is.
Question is, how does it know?
I believe the only solution is to use IF ELSE in decoder
sorry, i make mistake
_
与世界各地的朋友进行交流，免费下载 Live Messenger;
http://get.live.com/messenger/overview
i hear your project, in mina's mail-list.
i have 6 years experience on java, and 2 years experience on mina.
my sf.net account is 'szujobs'
my blog is http://www.cnblogs.com/jobs (chinese)
i want to learn BEEP, can i join the project?
[EMAIL PROTECTED]
__
I do not plan to implement the TLS and SASL tuning profiles of BEEP
(currently, there is no way to implement tuning profiles). I simply
do not need these features. However, if somebody is interested in
implementing them, I will not object a contribution. Contributions
are welcome... ;-)
O
I agree with mat-29.
In order for DemuxingProtocolCodecFactory to call a specific Decoder or
Encoder, it will need to know what the type of the message is.
Question is, how does it know?
Does it assume a specific value at a specific offset in the data stream?
Does it call all the Decoders in
Figured it out myself,
synchronizing on session.write does the job.
Johan
On 19 May 2007, at 17:33, Johan Cloetens wrote:
Hi,
I am having some trouble with the SSLFilter included in mina.
I have developed a rmi-like framework using mina.
It supports things like callbacks and oneway messages
Hi,
I am having some trouble with the SSLFilter included in mina.
I have developed a rmi-like framework using mina.
It supports things like callbacks and oneway messages,
so it isn't purely request/response based:
messages can flow in over the session either way
without any restrictions.
I hav
On the website I read : "It is unlikely that all the features of BEEP
will be implemented."
Could you tell me what will feature will be implemented and which
features will not?
_
Log på MSN Messenger direkte på nettet: http://webme
On May 18, 2007, at 8:47 PM, Matthew Phillips wrote:
This was all working reliably with 1.0.2, but in 1.1 it seems that
the reply is never seen by the client -- it appears that the
DisconnRply isn't getting flushed on session close. Changing the
code as below fixes the problem:
session.w
