Separation of Signal from Storage

Forgive me if this post is confusing. I've been trying to figure out how to write up something coherent for a few months and I simply have more questions than answers, which is a rough place to be when you want to start talking architecture.

For those paying really close attention, I was using (and occasionally co-maintaining) the D6 version of the Message module some time back. I was building an extended proof of concept for a high end stream service. That proof of concept hit performance limits on top of an RDBMS before the scope of the project increased by a couple orders of magnitude, so I silently faded away.

I am now contemplating something new: a really cool integration between Drupal and my company's fledgling Stream service. I don't want to dive too far into that here, but the main thrust is that I don't care about Drupal storage of the messages. Here's what I'm hoping to have:

• Ability to define message types.
• Ability to build a UI around "standard" message types to turn their auto-generation on or off. E.g., Node Created.
• Ability to implement an event listener that builds out the message with additional contextual information and pushes the resulting object at a RESTful service.

With that, I have the basis of the outbound part of a Stream service integration that can be installed in any Drupal site and be featurized or programmatically extended.

Why talk about that here? Well, as far as contrib goes, Message straddles the Action/Rules/Event/API line closer than most, and I believe it to have the high architectural concept that makes it a good place to try to have this conversation.

Is there space to separate Message into separate trigger and storage mechanisms? Should this be a separate system built around Rules? Is this a totally custom signalling system? I started doodling a Signals module with the idea that the response to a signal would be pluggable. I bounced between object oriented models and a hook_watchdog() approach. Ultimately I decided if there's room to collaborate, it would be a big win. And the setup for that needs to happen before I lay code ;p

My initial thought on this is one of two basic approaches. 1) What I described in the last paragraph: A signalling system that the storage-oriented aspects of Message would respond to. 2) A crazy RESTful PDO mechanism that disregards a lot of what's needed for the entity-based system. (Don't get me wrong, I'm poking at PDO, but that's a much deeper well.)