Call events running in local actor

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Call events running in local actor

Harry Vangberg-2
If I have an actor with access to a Call instance, and I want to do something with this actor on certain Call events, is there a better way to do the following:

class MyActor
  include Celluloid
 
  def initialize(call)
    call[:my_actor] = current_actor
    call.on_end do
      call[:my_actor].do_something
    end
  end

  def do_something
    # bla bla
  end
end

Event callbacks are always executed on the receiver, that is, the Call instance. How would I register events for a call, but execute the callback on my own actor? This works, but doesn't feel natural - and I have to generate UUIDs for the variable name if I want multiple instances of MyActor attached to the same call.

register_handler is also listed in `execute_block_on_receiver`, so that doesn't work.

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Call events running in local actor

Ben Langfeld-2
You cannot easily handle a Call's events outside of the Call actor. What you can do, though, is eliminate the naming issue you have by making use of the block's lexical scope, which is not rebound:

class MyActor
  include Celluloid
  
  def initialize(call)
    me = current_actor
    call.on_end do
      me.do_something
    end
  end

  def do_something
    # bla bla
  end
end

On 19 March 2015 at 19:17, Harry Vangberg <[hidden email]> wrote:
If I have an actor with access to a Call instance, and I want to do something with this actor on certain Call events, is there a better way to do the following:

class MyActor
  include Celluloid
 
  def initialize(call)
    call[:my_actor] = current_actor
    call.on_end do
      call[:my_actor].do_something
    end
  end

  def do_something
    # bla bla
  end
end

Event callbacks are always executed on the receiver, that is, the Call instance. How would I register events for a call, but execute the callback on my own actor? This works, but doesn't feel natural - and I have to generate UUIDs for the variable name if I want multiple instances of MyActor attached to the same call.

register_handler is also listed in `execute_block_on_receiver`, so that doesn't work.

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Call events running in local actor

Harry Vangberg-2
That will work. I find myself doing something like this quite often - what stands in the way of easily subscribing to a call's events outside of that actor? I would like to implement that, barring any major road blocks.

On 20 March 2015 at 09:16, Ben Langfeld <[hidden email]> wrote:
You cannot easily handle a Call's events outside of the Call actor. What you can do, though, is eliminate the naming issue you have by making use of the block's lexical scope, which is not rebound:

class MyActor
  include Celluloid
  
  def initialize(call)
    me = current_actor
    call.on_end do
      me.do_something
    end
  end

  def do_something
    # bla bla
  end
end

On 19 March 2015 at 19:17, Harry Vangberg <[hidden email]> wrote:
If I have an actor with access to a Call instance, and I want to do something with this actor on certain Call events, is there a better way to do the following:

class MyActor
  include Celluloid
 
  def initialize(call)
    call[:my_actor] = current_actor
    call.on_end do
      call[:my_actor].do_something
    end
  end

  def do_something
    # bla bla
  end
end

Event callbacks are always executed on the receiver, that is, the Call instance. How would I register events for a call, but execute the callback on my own actor? This works, but doesn't feel natural - and I have to generate UUIDs for the variable name if I want multiple instances of MyActor attached to the same call.

register_handler is also listed in `execute_block_on_receiver`, so that doesn't work.

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Call events running in local actor

Ben Langfeld-2
On 30 March 2015 at 15:57, Harry Vangberg <[hidden email]> wrote:
That will work. I find myself doing something like this quite often - what stands in the way of easily subscribing to a call's events outside of that actor? I would like to implement that, barring any major road blocks.

Nothing in particular, it's just never been proposed.
 
On 20 March 2015 at 09:16, Ben Langfeld <[hidden email]> wrote:
You cannot easily handle a Call's events outside of the Call actor. What you can do, though, is eliminate the naming issue you have by making use of the block's lexical scope, which is not rebound:

class MyActor
  include Celluloid
  
  def initialize(call)
    me = current_actor
    call.on_end do
      me.do_something
    end
  end

  def do_something
    # bla bla
  end
end

On 19 March 2015 at 19:17, Harry Vangberg <[hidden email]> wrote:
If I have an actor with access to a Call instance, and I want to do something with this actor on certain Call events, is there a better way to do the following:

class MyActor
  include Celluloid
 
  def initialize(call)
    call[:my_actor] = current_actor
    call.on_end do
      call[:my_actor].do_something
    end
  end

  def do_something
    # bla bla
  end
end

Event callbacks are always executed on the receiver, that is, the Call instance. How would I register events for a call, but execute the callback on my own actor? This works, but doesn't feel natural - and I have to generate UUIDs for the variable name if I want multiple instances of MyActor attached to the same call.

register_handler is also listed in `execute_block_on_receiver`, so that doesn't work.

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.