allow actors to send ad-hoc messages?

[arschles]

this discussion started in response to issue 4 (http://code.google.com/
p/pysage/issues/detail?id=4)

this task probably should come after the networking stack is in order.
it would be useful to allow actors to be able to send messages ad-hoc
without first creating a new message class. this functionality could
be implemented in a few different ways (using the example of an actor
wanting to send an ad-hoc "message received" message):

I. The trigger_to_actor method could be extended to accept strings as
the message
<code>
ActorMgr.get_singleton().trigger_to_actor(target_actor_id, "message
received")
</code>

II. The trigger_to_actor method would stay the same, and an
AdHocMessage message type could be built in to pysage
<code>
ActorMgr.get_singleton().trigger_to_actor(target_actor_id, AdHocMessage
("message received"))
</code>

In all of the above implementations, the trigger_to_actor method would
still have to be responsible for ensuring that the message gets to its
target as a well formed message, so that actors can be written without
having to know whether the message sender send an ad-hoc or structured
(ie: in a custom message class) message.

thoughts? comments?

[John Yang]

This could be tricky. I do want the subscription system to work
nicely with this.

More specifically, what I mean is that not every actor has to listen
to "adhoc" messages. Therefore, I can say that I'm sending a
"BombMessage" without having to write a BombMessage class and only
actors who subscribed to "BombMessage" would process it. Of course,
this message would now need to send extra meta data, because the other
end would not know the structure of the data received.

This also raises questions about maintainability. It is now easier to
send a message of "BombMessage" that contains a text and somewhere
else send another "BombMessage" that contains a number, because we are
missing a concrete message class.

John

[arschles]

good point, John. perhaps it's better then to include with pysage a
set of commonly used message classes instead of allowing ad-hoc
messages. the more I think about it, the more it seems like a
maintenance nightmare for users and implementors alike to have two
ways to send messages.

here are some ideas for prefab message classes (names left long for
clarity):

* JSONMessage
* BeginWorkerMessage
* MessageReceiptAcknowledgmentMessage
* ComputationCompletedMessage
* ProgressNotifierMessage
* DecisionRequestMessage

On Apr 11, 11:39 pm, John Yang <bigjh...@gmail.com> wrote:
> This could be tricky.  I do want the subscription system to work
> nicely with this.
>
> More specifically, what I mean is that not every actor has to listen
> to "adhoc" messages.  Therefore, I can say that I'm sending a
> "BombMessage" without having to write a BombMessage class and only
> actors who subscribed to "BombMessage" would process it.  Of course,
> this message would now need to send extra meta data, because the other
> end would not know the structure of the data received.
>
> This also raises questions about maintainability.  It is now easier to
> send a message of "BombMessage" that contains a text and somewhere
> else send another "BombMessage" that contains a number, because we are
> missing a concrete message class.
>
> John
>

[Cosmin Stejerean]

Here are some thoughts:

* In certain instances an actor needs to send a simple message directly to another actor, often in response to an earlier message.

* There are types of messages that only make sense to send to a single actor, never to a group.

* In order to both eliminate the need to create a message class for these simple messages, and to prevent them from being sent out to a group by accident we need a new way of sending messages.

* The receiver however still needs to specify that they accept this message and declare how it should be handled

For lack of a better term we can continue to call these type of messages 'adhoc messages'. Here are some notes on implementation.

* adhoc messages are sent by name and only directly to another actor.

* having an adhoc message and a regular message of the same name is an error. the easiest way to detect this is to check when sending an adhoc message if a regular message of the same name has been declared, and fail if so.

* as a first step adhoc messages should probably not contain any data. it is possible to relax this limitation going forward to send a single data value with an adhoc message.

So the syntax for sending an adhoc message should be:

  trigger_to_actor(some_actor, 'SomeMessage')  

which closely mirrors the syntax for sending regular messages of 

  trigger_to_actor(some_actor, SomeMessage())

There should not be any differences between receiving adhoc messages and regular messages, so the receiver still needs to list 'SomeMessage' in the list of messages it subscribes to, and implemented handle_SomeMessage.

Thoughts?

--
Cosmin Stejerean
http://offbytwo.com

[John Yang]

Aaron:

Does this address your concern of ad-hoc messages? As a example, the
code below would not require us to write a specific message class.

[begin]

trigger_to_actor(gui_actor, 'ComputationCompletedMessage')

class WorkerActor(actor):
subscriptions = ['ComputationCompletedMessage']
def handle_ComputationCompletedMessage(self, msg):
pass

[end]

John

[arschles]

Hey Cosmin & John,

The proposal addresses my concerns, at least as a first step. One
question for Cosmin: why impose the restriction that ad-hoc messages
can only be sent directly to another actor?

-Aaron

On Apr 12, 9:43 pm, John Yang <bigjh...@gmail.com> wrote:
> Aaron:
>
> Does this address your concern of ad-hoc messages?  As a example, the
> code below would not require us to write a specific message class.
>
> [begin]
>
> trigger_to_actor(gui_actor, 'ComputationCompletedMessage')
>
> class WorkerActor(actor):
>     subscriptions = ['ComputationCompletedMessage']
>     def handle_ComputationCompletedMessage(self, msg):
>         pass
>
> [end]
>
> John
>

[Cosmin Stejerean]

On Mon, Apr 13, 2009 at 10:17 PM, arschles <arsc...@gmail.com> wrote:

Hey Cosmin & John,

The proposal addresses my concerns, at least as a first step. One
question for Cosmin: why impose the restriction that ad-hoc messages
can only be sent directly to another actor?

The reason is mostly philosophical. I like the idea of supporting ad-hoc communication between two actors, but I think it is proper to create a proper message for communicating with a group of actors. This provides a clear separation between ad-hoc messages and regular messages and makes it obvious which one is appropriate in any given situation.

From an implementation perspective it should be also simpler to add ad-hoc messages if we only have to extend trigger_to_actor.

[arschles]

Sounds good, Cosmin.

On Apr 13, 8:36 pm, Cosmin Stejerean <cstejer...@gmail.com> wrote:

[John Yang]

This feature (adhoc trigger_to_actor) is now implemented in pysage trunk.

Exception "ConcreteMessageAlreadyDefined" will be raised if an adhoc
message is sent while a concrete message class with the same name is
already defined.

Aaron, thanks for the suggestion. Cosmin, thanks for the thoughts.

John