Scala bindings

[Niklas Gustavsson <ni...@protocol7.com>]

Hi

Rich Dougherty has developed MINA bindings for Scala
(https://issues.apache.org/jira/browse/DIRMINA-499) that was
previously rejected from inclusion into MINA due to the lack of
committer support. I would now be happy to provide that support. Rich,
would you still be interested in contributing the bindings to the MINA
project? The rest of you, would you find bringing these into the main
project a good idea?

/niklas

Re: Scala bindings

[Niklas Gustavsson <ni...@protocol7.com>]

On Sun, Apr 12, 2009 at 10:10 AM, Niklas Gustavsson
<ni...@protocol7.com> wrote:
> Oh, sure. If we import it I would suggest we put it into the sandbox
> until we feel more confident in that it's ready to be part of the core
> project.

Anyone got an opinion on if we need a Software grant for this contribution?
http://www.apache.org/licenses/#grants

/niklas

Re: Scala bindings

[Emmanuel Lecharny <el...@apache.org>]

> Btw, aren't your out sailing or something? :-)

I'm ! Sea, sun, a bit of wind, lot of fun !

But no computer :/

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Scala bindings

[Niklas Gustavsson <ni...@protocol7.com>]

On Sat, Apr 11, 2009 at 12:56 AM, Emmanuel Lecharny
<el...@apache.org> wrote:
> Niklas Gustavsson wrote:
>> Rich Dougherty has developed MINA bindings for Scala
>> (https://issues.apache.org/jira/browse/DIRMINA-499) that was
>> previously rejected from inclusion into MINA due to the lack of
>> committer support.
>
> It was not rejected. The patch is still pending in JIRA :
> https://issues.apache.org/jira/browse/DIRMINA-499

Rejected might have been to wrong wording. "Not accepted for the time
being" might be a better choice :-)

>> I would now be happy to provide that support. Rich,
>> would you still be interested in contributing the bindings to the MINA
>> project? The rest of you, would you find bringing these into the main
>> project a good idea?
>>
>
> That's fine as soon as some one document it up to a point it can be
> maintained...

Oh, sure. If we import it I would suggest we put it into the sandbox
until we feel more confident in that it's ready to be part of the core
project.

Btw, aren't your out sailing or something? :-)

/niklas

Re: Scala bindings

[Emmanuel Lecharny <el...@apache.org>]

Niklas Gustavsson wrote:
> Hi
>
> Rich Dougherty has developed MINA bindings for Scala
> (https://issues.apache.org/jira/browse/DIRMINA-499) that was
> previously rejected from inclusion into MINA due to the lack of
> committer support. 
It was not rejected. The patch is still pending in JIRA :
https://issues.apache.org/jira/browse/DIRMINA-499

> I would now be happy to provide that support. Rich,
> would you still be interested in contributing the bindings to the MINA
> project? The rest of you, would you find bringing these into the main
> project a good idea?
>   
That's fine as soon as some one document it up to a point it can be 
maintained...
> /niklas
>
>   


-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Scala bindings

[Rich Dougherty <ri...@rd.gen.nz>]

On Sun, Apr 12, 2009 at 8:11 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Sat, Apr 11, 2009 at 5:22 AM, Rich Dougherty <ri...@rd.gen.nz> wrote:
>> That sounds great. The main issue that (IMO) needs resolving is flow
>> control. At the moment, MINA events are converted to actor messages. It
>> might be possible for events to arrive too quickly and use up all memory. I
>> think there needs to be some sort of communication back from the actor so
>> that MINA can hold off sending new events until it is ready.
>
> Isn't this the general issue about flow control in MINA, with or without Scala?

I think it's a slightly different issue. I'm talking about the fact
that the IoHandler implementation for the Scala bindings basically
does something like:

  def messageReceived(session: IoSession, message: Any) = {
    ...
    sessionActor ! MessageReceived(message)
  }

There is no acknowledgement back from the sessionActor at all. As far
as the rest of MINA knows, the message has been handled as soon as the
messageReceived method returns. But all we've done is sent an
asynchronous notification to the session actor; we don't know when it
will actually be processed. MINA's existing flow control code would
not be able to know whether or not the message has been handled.

Cheers
Rich

--
http://blog.richdougherty.com/

Re: Scala bindings

[Niklas Gustavsson <ni...@protocol7.com>]

On Sat, Apr 11, 2009 at 5:22 AM, Rich Dougherty <ri...@rd.gen.nz> wrote:
> That sounds great. The main issue that (IMO) needs resolving is flow
> control. At the moment, MINA events are converted to actor messages. It
> might be possible for events to arrive too quickly and use up all memory. I
> think there needs to be some sort of communication back from the actor so
> that MINA can hold off sending new events until it is ready.

Isn't this the general issue about flow control in MINA, with or without Scala?

/niklas

Re: Scala bindings

[Rich Dougherty <ri...@rd.gen.nz>]

Hi Niklas

That sounds great. The main issue that (IMO) needs resolving is flow
control. At the moment, MINA events are converted to actor messages. It
might be possible for events to arrive too quickly and use up all memory. I
think there needs to be some sort of communication back from the actor so
that MINA can hold off sending new events until it is ready.

I haven't thought about a solution to this yet. (Since writing the Scala
bindings, I've been mainly exploring other approaches to IO on Scala.)

Cheers
Rich

On Sat, Apr 11, 2009 at 9:26 AM, Niklas Gustavsson <ni...@protocol7.com>wrote:

> Hi
>
> Rich Dougherty has developed MINA bindings for Scala
> (https://issues.apache.org/jira/browse/DIRMINA-499) that was
> previously rejected from inclusion into MINA due to the lack of
> committer support. I would now be happy to provide that support. Rich,
> would you still be interested in contributing the bindings to the MINA
> project? The rest of you, would you find bringing these into the main
> project a good idea?
>
> /niklas
>