[cap-talk] Regarding AMQP Messaging paradigm and pattern in E
john.carlson3 at sbcglobal.net
Mon Apr 5 15:46:26 PDT 2010
I think what you have to do is what most IM systems do. A directory (say email addresses or usernames) is available for all participants. If someone wants to talk with someone else, they send them a capability that allows the other party to send them a capability (a bootstrap mechanism). The second party can easy ignore the first capability. The first capability is forced by the system to only be sent once per publisher/consumer pair--or the second party can ignore all future capabilities.
Hopefully I have explained this well enough.
On Apr 5, 2010, at 2:14 PM, Yuvaraj Athur Raghuvir wrote:
> Recently I came across AMQP (www.amqp.org) which defines an interesting, extensible and flexible message routing paradigm. The three major elements are exchange, binding and queues. With these three constructs, many of the standard messaging patterns can be realized.
> From my understanding, computation is moving towards the network and thus, messaging and routing starts to play an important role.
> In Capability based systems (OCAP), the management of capability is through explicit exchange of reference - the Granovetter diagram. This defines a point-to-point interaction model. In the world of messaging, this point-to-point seems to be one case of the possible many. Further, it is now becoming important that the messages are delivered not on a destination specification but on a pattern based specification of the destination. This allows for time independence of message creation and delivery.
> Since the AMQP decouples the publisher via the exchange and the consumer via the queue, and manages the relation between the exchange and queue via binding, I wonder what would be the corresponding security pattern in E-Language. In particular, how to create a binding between the exchange and queue so that the security paradigm is not violated?
> Any thoughts?
> cap-talk mailing list
> cap-talk at mail.eros-os.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cap-talk