Closed maurerle closed 2 weeks ago
Oh good point, I missed on that. It should be sufficient to just delete the overridden property addr in RoleContext, as RoleContext extends AgentDelegates. There are some other things I wanna change and release today or tomorrow, this will then be part of it.
There is also something funky with the create_acl function:
Currently, I need to do:
self.context.schedule_instant_message(
create_acl(content={
"context": "data_response",
"data": data,
},
receiver_addr=meta["sender_addr"],
sender_addr=self.context.addr.protocol_addr,
acl_metadata={
"in_reply_to": meta.get("reply_with"),
},
),
receiver_addr=sender_addr(meta),
)
This is not very readable, as one part requires the receiver_addr, while the other wants the protocol_addr. On the other hand, the create_acl function works around if some parameters are given in the dict instead of as a param, but the param is required and can not be left off.
The FIPA ACL standard does actually not say to have a receiver_addr and receiver_id separated: http://www.fipa.org/specs/fipa00061/SC00061G.html#_Toc26669700
Maybe we can find a better way to do this here too. :)
Though this has not much to do with the initial issue, but is part of the incosistency I stumbled across.
I would just change it such that AgentAddresses are expected to sender_addr and receiver_addr, and I would remove the receiver_id consequently.
an agent is from
AgentDelegates
and has access tomyagent.addr
<- this is a property withAgentAddress(self.context.addr, self.aid)
when I have the role at hand, I can do - as usual -
self.context.addr
this givesAgentContext.addr
which is a property toself._container.addr
which is the protocol_addr. I think this is quite ambiguous now.I would like to have the same property as in the AgentDelegates for the Role itself instead of doing
AgentAddress(self.context.addr, self.aid)
manually there.