You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2005/05/09 01:21:56 UTC
[mina] Integrating I/O layer and Protocol layer
Hi all,
I've just got up in my bed, and got a new idea about integrating I/O
layer and Protoocol layer.
Here's my idea:
1. Remove I/O layer interfaces and merge them into protocol layer interfaces
2. Acceptors and Connectors fire messageReceived and messageSent event
whose messages are ByteBuffers; users will have to downcast them to
ByteBuffers.
3. ProtocolCodecs are implemented as filters; users will have to add
their own filters or predefined codec filters to perform
transformation between ByteBuffers and custom objects. (i.e.
ProtocolCodecs are generalized to filters)
This change removes distinction between I/O layer and Protocol layer,
and therefore brings us more unified API though users of I/O layer
only will have to downcast message objects to ByteBuffers, but I think
it doesn't matter actually.
We have released 0.7 internally, so we could apply this idea to 0.9
branch. WDYT?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] Integrating I/O layer and Protocol layer
Posted by Trustin Lee <tr...@gmail.com>.
Hi Vinod,
Thanks for your fast feedback, I created a branch called
'api_integration'. I'll let you know when it is ready.
2005/5/9, Vinod Panicker <vi...@gmail.com>:
<snip/>
> > 2. Acceptors and Connectors fire messageReceived and messageSent event
> > whose messages are ByteBuffers; users will have to downcast them to
> > ByteBuffers.
>
> All the attributes of the "Session" would still be completely configurable?
Yes of course.
> > This change removes distinction between I/O layer and Protocol layer,
> > and therefore brings us more unified API though users of I/O layer
> > only will have to downcast message objects to ByteBuffers, but I think
> > it doesn't matter actually.
>
> I'd actually prefer a bit more flexibility here. Let me think on this
> a little bit. Downcasting if u wanna do raw I/O is not really
> desirable.
Yeah downcasting is error prone. But we did downcasting when we
implement ProtocolHandlers, too. I'm looking forward to your
solution. :)
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] Integrating I/O layer and Protocol layer
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
2005/5/9, Vinod Panicker <vi...@gmail.com>:
> I've changed my reply-to address to blank. Do let me know if the
> problem persists.
k, I'll.
> Also, regarding the messageReceived method, we can have a new object
> of Message being passed, which will provide getter methods to the
> Protocol Object and the raw ByteBuffer as well.
Could you explain this again? I don't get it exactly.
> If we could use JDK 5 generics, we could have the message object being
> instantiated with the object type directly, be it a ByteBuffer /
> Protocol object.
This idea is cool. We could use retroweaver to generate 1.4 jar file.
But we'll have to release 1.4 jar and 1.5 jar separately, and Maven
doesn't support this. Any ideas on this?
BTW I checked in merged code to api_integration branch. I checked
Echo Server and Reverser works fine. Could you review this?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] Integrating I/O layer and Protocol layer
Posted by Vinod Panicker <vi...@gmail.com>.
On 5/9/05, Trustin Lee <tr...@gmail.com> wrote:
> Hi,
--snip--
> Oh really? I'm using Gmail, too, but my gmail doesn't put other's id
> but yours. Could you check your Gmail settings? I'll, too.
>
I've changed my reply-to address to blank. Do let me know if the
problem persists.
Also, regarding the messageReceived method, we can have a new object
of Message being passed, which will provide getter methods to the
Protocol Object and the raw ByteBuffer as well.
If we could use JDK 5 generics, we could have the message object being
instantiated with the object type directly, be it a ByteBuffer /
Protocol object.
Regards,
Vinod.
Re: [mina] Integrating I/O layer and Protocol layer
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
2005/5/9, Vinod Panicker <vi...@gmail.com>:
> On 5/9/05, Trustin Lee <tr...@gmail.com> wrote:
> > BTW you don't need to include my e-mail address to recipients because
> > I already subscribed to dev@directory.apache.org as you know. :)
> >
>
> I dont do it on purpose - with your address, gmail automatically puts
> your id in the sender list. Will remove it manually from now.
Oh really? I'm using Gmail, too, but my gmail doesn't put other's id
but yours. Could you check your Gmail settings? I'll, too.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] Integrating I/O layer and Protocol layer
Posted by Vinod Panicker <vi...@gmail.com>.
On 5/9/05, Trustin Lee <tr...@gmail.com> wrote:
> BTW you don't need to include my e-mail address to recipients because
> I already subscribed to dev@directory.apache.org as you know. :)
>
I dont do it on purpose - with your address, gmail automatically puts
your id in the sender list. Will remove it manually from now.
Vinod.
Re: [mina] Integrating I/O layer and Protocol layer
Posted by Trustin Lee <tr...@gmail.com>.
BTW you don't need to include my e-mail address to recipients because
I already subscribed to dev@directory.apache.org as you know. :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] Integrating I/O layer and Protocol layer
Posted by Vinod Panicker <vi...@gmail.com>.
Hi Trustin,
On 5/9/05, Trustin Lee <tr...@gmail.com> wrote:
> Hi all,
>
> I've just got up in my bed, and got a new idea about integrating I/O
> layer and Protoocol layer.
>
> Here's my idea:
>
> 1. Remove I/O layer interfaces and merge them into protocol layer interfaces
Great.
> 2. Acceptors and Connectors fire messageReceived and messageSent event
> whose messages are ByteBuffers; users will have to downcast them to
> ByteBuffers.
All the attributes of the "Session" would still be completely configurable?
> 3. ProtocolCodecs are implemented as filters; users will have to add
> their own filters or predefined codec filters to perform
> transformation between ByteBuffers and custom objects. (i.e.
> ProtocolCodecs are generalized to filters)
Perfect use of filters. It was a bit clunky to necessarily implement
a codec even when it wasnt needed. This takes care of it.
> This change removes distinction between I/O layer and Protocol layer,
> and therefore brings us more unified API though users of I/O layer
> only will have to downcast message objects to ByteBuffers, but I think
> it doesn't matter actually.
I'd actually prefer a bit more flexibility here. Let me think on this
a little bit. Downcasting if u wanna do raw I/O is not really
desirable.
> We have released 0.7 internally, so we could apply this idea to 0.9
> branch. WDYT?
>
+1
Regards,
Vinod.
Re: [mina] Integrating I/O layer and Protocol layer
Posted by Alex Karasulu <ao...@bellsouth.net>.
Alex Karasulu wrote:
> Trustin Lee wrote:
>
> Trustin this sounds very exciting but gimme sum time I'm swamped.
> Also have to answer to Endi as well.
You got to love that English: "gimme sum"
:)
Alex
Re: [mina] Integrating I/O layer and Protocol layer
Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:
>Hi all,
>
>I've just got up in my bed, and got a new idea about integrating I/O
>layer and Protoocol layer.
>
>Here's my idea:
>
>1. Remove I/O layer interfaces and merge them into protocol layer interfaces
>2. Acceptors and Connectors fire messageReceived and messageSent event
>whose messages are ByteBuffers; users will have to downcast them to
>ByteBuffers.
>3. ProtocolCodecs are implemented as filters; users will have to add
>their own filters or predefined codec filters to perform
>transformation between ByteBuffers and custom objects. (i.e.
>ProtocolCodecs are generalized to filters)
>
>This change removes distinction between I/O layer and Protocol layer,
>and therefore brings us more unified API though users of I/O layer
>only will have to downcast message objects to ByteBuffers, but I think
>it doesn't matter actually.
>
>We have released 0.7 internally, so we could apply this idea to 0.9
>branch. WDYT?
>
>
Trustin this sounds very exciting but gimme sum time I'm swamped. Also
have to answer to Endi as well.
My appologies to both of you,
Alex