Broadcast Style Listeners Specification Google Document

Completed and ready for public comment.

The google document for this proposed feature enhancement is at http://docs.google.com/Doc?id=dhjcwfn4_38gnmpfc

It's not entirely clear to me from the proposed docs, but what happens when you have:

<event-handler event="someEvent" access="public">

<publish message="needPrimates"/> <---waitForThreads="false"
<notify listener="someListener" .... />
<notify listener="someOtherListener" ... />

</event-handler>

Will the "old school" method calls on the listeners in the above command then run in parallel with the "published" message (whose own defined commands are running in parallel), or will they wait for the published event methods to finish running?

Will it be CF 7 compatible? If you're gonna have to test for CF Engine vendor and version anyway, would it make sense to also make this CF 7 compatible (i.e., no cfthread)? The order of execution could still be unspecified.

Bklass:

waitForThreads will kick off the message and continue with the next command. This would be akin to using an event gateway (like JMS). So in your example, the publishing of "needPrimates" would not wait to complete before the notify commands are run nor could you get data back from "needPrimates" since the attribute says not to wait for it. So in essence, the each notify will run in serial to each other while being run in parallel with the publish command (since you have noted it will run as waitForThreads="false").

Matt:

Yes, it will run on CF engines that don't support cfthread. The spec states:

If the Mach-II application is deployed on a ColdFusion engine that does not support cfthread, Mach-II will automatically run all published message subscribers in serial (i.e. Mach-II ignores the asyncronise threading directive).

Not to through a wrench at you guys, but I'm not sure if we really truly need this. It provides a layer of abstraction, but I've never really heard anyone complain about this. Sean's implementation may have been an "exercise", but I'd like to know more about the volume of comments thats caused this to be added or proposed.

Also, in what business case would this really add value to M2? Where would you need to execute a threaded listener and execute the view possibly before the thread even finishes. The only scenario I could think of is of logging events, etc, where it doesnt affect the view. Am I right that we also lose control over the sequence of listeners inside publish?

I guess to summarize, I'd like to see a real scenario besides "primates", and have greater visibility on the impetus for this feature.

Why publish? Why not broadcast?

Also, how is this a problem: "There has been discussions in the past that Mach-II does not allow for multiple listener notifications via a single "broadcast" command. Model-Glue's entire listener (aka controllers in Model-Glue) works on a broadcast system versus Mach-II somewhat more direct approach with the <notify> command. Any listeners have has a registered interest in a particular broadcasted message will receive the message for use. This allows you to invoke multiple listener methods by broadcasting a single message."

Wouldn't a problem be a valid scenario where NOT having broadcasting is causing woes.

@Sami:

The "broadcast" idea has been kicked around in the community for a long time. Quit honestly I did not feel the need until the recent past. It's hard to put a complete example in the comments here, but consider publishing a message called "needAdmin" which could be comprised of many piece of data that is gotten through a few subscribers. In a current application of mine, this involves 5 notify commands which is repeated in several different event-handlers. It would be much easier to say "needAdmin" versus all those notify commands. In my current applications, it would reduce the times I forgot to update the other event-handlers when using notify.

In addition, the threading could be used to kick off a process that generates a PDF and return a view saying that the PDF is being generated. Using the thread ID (since all threads will get ID), it would easier to query the status of the PDF generation (whether or not it's waiting in the thread queue or being processed). Upon the completion of the PDF, it could send a completed email to the user and remove itself from the list of threads that the user has a registered interest in.

@Brian, this whole concept is based on the observer pattern (aka publish/subscribe). Publish/subscribe is an asynchronous messaging paradigm - which the this spec certainly allows fo via the waitForThreads attribute. Plus those verbs are more inline with the other vocabulary in Mach-II (IMO). Otherwise it would broadcast/receive. Thoughts?

@Anon, correct the problem is poorly outlined in the spec - I will try to correct that soon. However, it is trying to state that notify is directly asking a single listeners for data whereas publish lets listeners register an interest in a message and indirectly perform their data getting.

I wanted to point out an interesting point that Jorge Loyo brought on the Mach-II blog:

I think this would help in the creation and maintenance of applications since you can change the listener(s) managing the event without modifying the event-handler. In my opinion it's a great addition to the framework and it would provide a little flexibility to satisfy different programing preferences.

Not that I swap my listeners out a lot, it would allow for some additional flexibility if you use different listeners on an application that is customize repeatedly for clients. I could see the use of config file includes that override default behavior with client specific listeners (and subscribers).

I'll post the comment here that I just posted on the blog:

Overall this looks great. It's a nice clean proposed syntax. I like the integrated threading model. Some nit-picks and questions below.

"In the body of each listener tag" - you mean "message tag"?

Why duplicate the message name in "subscribe message="needPrimates"" - is that just a typo? The message name is already specified in the enclosing message tag.

Under "Subscribe Tag Attributes", you have a message attribute (which seems unnecessary) but omit the listener attribute (which *is* necessary).

Can you specify any child tags for the publish verb? (In Model-Glue you can specify additional arguments for the message).

The decoupling of the notify/listener pair is very powerful and right now it's my biggest sticking point with using Mach-II. Once they are decoupled, you can easily register a logging / auditing listener for messages without affect the main flow of the application. You can also refactor listeners much more easily, breaking one listener into multiple methods, perhaps in other listeners, without having to edit all of the event handlers. Jorge's point is actually a bigger issue for maintenance than I suspect most people realize.

@Peter, as stated elsewhere, I LOVE the idea, whatever it's called.

I was typing the same last two comments here but Sean beat me to it.

1) Can you pass parameters/arguments to the publish call, like you can in Model-Glue? 2) I do this now by having listener methods that call multiple other methods, and it works great. I don't know if I'd refactor existing code unless there's a performance gain.

All of those are typos and have been fixed. The XML has changed a lot since we started this doc and given my limited time to work on the project -- I missed it.

Sean Corfield says:

Can you specify any child tags for the publish verb?

No, this would reintroduce coupling to the event-handler again. This is why listener methods will not know the name of the message that called it. We want to keep things simple.

Jorge's point is actually a bigger issue for maintenance than I suspect most people realize.

Agreed, this is one of the reasons why we want to introduce this feature. We didn't mention this in the spec and I will add this as a reason.

Peter,

I look forward to the updated doc. Looking at the comments, I'm seeing more uses for this, and it definitely does look like a good idea. I think of one of the main things you'll want to clarify is how this is different from subroutines. Is it just the async aspect of it? Also, could a subroutine 'publish'? The interplay between these new features will require some clear documentation... i.e. if you are intending this, go this route, if you need XYZ, go this route. I guess this where the use cases also come in handy.

Sami

<publish> is another way to invoke one or more listener methods. Multiple listener methods could subscribe to the same published message whereas <notify> directly calls one listener method. Of course, <publish> is completely decoupled from event handlers where <notify> does introduce some coupling to event handlers (not to mention the limitation of one listener invocation).

Subroutines merely encapsulate snippets of xml code which could include <publish> commands and are not really related to this proposed enhancement. For example, we recommend to use a subroutine to do a layout versus annoucing another event. Another example could be a search box in which you need user data to populate drop downs. In the past you would have to get the data and build the search box which is fine. What about when you want to use that search box widget on other pages? Before subroutines you would have had to duplicate many lines of xml (getting data and building the view) in several different event handlers. This is prone to errors introduced during the maintenance of the application as it's easy to forget all the event handlers this widget is used on. Subroutines allow you to encapsulate all of that xml into one snippet and then you would reference <execute subroutine="searchWidget" /> in an event handler. Subrotines are executed immediate (not queued) and they have access to the same event object as the event handler that executed it. As you can see it just solves a problem that many people face that couldnt be handled by queing another event.

FYI, the Google Doc is set to automatic publishing - so when ever anybody on Team Mach-II saves a change - it is reflected on the published version.

You've got me hooked. Makes sense!

As noted in ticket #7, a mostly complete alpha for this feature was checked in as changeset:551. Support for BD is next.

Replying to peterfarrell:

Broadcast style listeners spec

Sweet I like where mach II is going! Keep up the good work PF and crew!