launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 27 September 2010 23:46, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> On 09/24/2010 05:45 PM, Martin Pool wrote:
>> On 24 September 2010 23:27, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
>> Right.  I was wondering if Launchpad was going to (now, or later)
>> change to just sending "this branch tip changed" and then have the
>> recipients decide what to do with that.  For instance, we want to
>> update precalculated mp preview diffs when the branch changes.
>> Ideally, in a message system, the branch scanner wouldn't need to know
>> anything about that, only the job that's subscribed to those events.
>
> We are already pretty decoupled there.  When the scanner notices a
> branch tip change, it fires a TipChanged event.  One of the subscribers
> generates the appropriate UpdatePreviewDiffJob.

That's what I meant: it seems like we already have both pubsub and
task-dispatch type messaging.  Perhaps we are happy having the events
happen entirely in process for now, but if we're considering future
architecture perhaps it should be taken into account.

>> If we want to take that direction perhaps it's better not considering
>> it only as a task dispatch system?
>
> I don't know about that.  It's quite useful to represent this as a job,
> not an event.  (You could do an event message which generates a job
> message, but that seems inefficient to me.)

But isn't that basically what you described above?  Or are you saying
it would be inefficient to do an event passed out to an external
broker rather than just transmitted within zope?

> We can then inform our users that a diff is pending (and maybe
> distinguish between "pending" and "in progress").  This is a real-world
> example of imperative messages imply an expected consequence, while
> informative messages don't, and leave us less-informed as a consequence.

Nice example, particularly that if you know you requested a task
rather than just sending a message you can check its status,
potentially cancel it, etc.

-- 
Martin