<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
<div>
<div>On May 10, 2011, at 11:07 AM, Matt Dietz wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>Alright, I'll buy it. Simply adding a UUID would be trivial<br>
<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br>
</font></font></div>
</blockquote>
<div><br>
</div>
<div>Cool.</div>
<div><br>
</div>
<blockquote type="cite">
<div>Regarding categories, I tend to agree with Jay on this. I think it would<br>
be treacherous to try to account for any number of possibilities, and I<br>
also think that we need to keep this as simple as possible.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>Okay fair enough, the external publisher may create categories as needed.</div>
<br>
<blockquote type="cite">
<div>On 5/10/11 10:35 AM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
<br>
<blockquote type="cite">On Mon, May 9, 2011 at 11:58 PM, Jorge Williams<br>
</blockquote>
<blockquote type="cite"><<a href="mailto:jorge.williams@rackspace.com">jorge.williams@rackspace.com</a>> wrote:<br>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">On May 9, 2011, at 6:39 PM, Matt Dietz wrote:<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">Jorge,<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"> Thanks for the feedback!<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"> Regarding the message format, we actually don't need the unique id<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">in the<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">generic event format because that's implementation specific. The<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">external<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">publisher I've implemented actually does all of the pubsubhubbub<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">specific<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">heavy lifting for you. The idea behind keeping this system simple at the<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">nova layer is allowing people to implement anything they'd like, such as<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">emails or paging.<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">I guess, I'm not seeing the whole picture. So these are internal<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">messages?<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">Will they cross service boundaries / zones? I'm sorry I missed the<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">conversation at the summit :-) Is there a blueprint I should be reading?<br>
</blockquote>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">On this particular point, I agree with Jorge. A unique identifier<br>
</blockquote>
<blockquote type="cite">should be attached to a message *before* it leaves Nova via the<br>
</blockquote>
<blockquote type="cite">publisher. Otherwise, subscribers will not be able to distinguish<br>
</blockquote>
<blockquote type="cite">between different messages if more than one publisher is publishing<br>
</blockquote>
<blockquote type="cite">the message and tacking on their own unique identifier.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">For instance, if a Rabbit publisher and email publisher are both<br>
</blockquote>
<blockquote type="cite">enabled, and both attach a unique identifier in a different way,<br>
</blockquote>
<blockquote type="cite">there's no good way to determine two messages are the same.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">For categories, were you considering this to be a list? Could you give<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">an<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">example of an event that would span multiple categories?<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">From an Atom perspective, I suppose anything a client might want to key<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">in<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">on or subscribe to may be a category. So "create" may be a category --<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">a<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">billing layer may key in on all create messages and ignore others.<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">"compute"<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">may also be a category -- you can aggregate messages from other<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">services so<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">It'd be nice for messages from compute to have their own category. To<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">my<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">knowledge, atom doesn't have the concept of priority so "WARN" may also<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">be a<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">category. I suppose if these are internal messages an external<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">publisher<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">can split the event_type and priority into individual categories.<br>
</blockquote>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">I disagree with this assessment, Jorge, for this reason: attempting to<br>
</blockquote>
<blockquote type="cite">identify all the possible categories that an organization may wish to<br>
</blockquote>
<blockquote type="cite">assign to a particular event may be near impossible, and in all<br>
</blockquote>
<blockquote type="cite">likelihood, different deployers will have different categories for<br>
</blockquote>
<blockquote type="cite">events.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">I think a solution of codifying the event_type in the message to a<br>
</blockquote>
<blockquote type="cite">singular set of strings, with a single dotted group notation (like<br>
</blockquote>
<blockquote type="cite">"instance.create" or something like that) is the best we can do. The<br>
</blockquote>
<blockquote type="cite">subscriber of messages can later act as a translation or aggregator<br>
</blockquote>
<blockquote type="cite">based on the business rules in place at the deployer. For example,<br>
</blockquote>
<blockquote type="cite">let's say a deployer wanted to aggregate messages with event_type of<br>
</blockquote>
<blockquote type="cite">"instance.create" into two categories "instance" and "create". A<br>
</blockquote>
<blockquote type="cite">custom-written subscriber could either do the aggregation itself, or<br>
</blockquote>
<blockquote type="cite">modify the message payload to include these custom deployer-specific<br>
</blockquote>
<blockquote type="cite">categories.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">Hope that makes sense.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">-jay<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</body>
</html>