Skip to content

Instantly share code, notes, and snippets.

@ifandelse

ifandelse/changes.md

Created May 25, 2012 03:30
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save ifandelse/2785593 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save ifandelse/2785593 to your computer and use it in GitHub Desktop.
Download ZIP
Postal.js Bindings Resolver - Looming Changes....
Raw
changes.md

Darn Straight - change is coming

The Way Postal.js Handles Topic Bindings Is About to Change

postal.js currently supports wildcard topic bindings by providing two special characters that can be used in a binding. The current implementation works as follows:

  • Topics are period-delimited string values. Periods are not required, but if they are included, the section of alpha-numeric text between periods is referred to as a word or topic segment.
  • Current wildcard characters:
    • "*" - an asterisk acts as a wildcard for any length of the topic.
      • "Home*" would match "Home.Sweet.Home" and "Homeless.Programmer"
      • "Home.*" would match "Home.Sweet.Home, but not "Homeless.Programmer"
    • "#" - a hash symbol current matches one "word" of a topic.
      • "Home.# would match "Home.Boy" but not "Home.Sweet.Home"

#Y U WANT CHANGE POSTAL?

postal.publish("Epic Fail")

Simple: The wildcard rules above are the flat inverse of the AMQP standard.

  • I've borrowed key conceptual ideas from AMQP, and want to remove this mental 'impedance mismatch'
  • Future postal.js endeavors include bridging instances of postal with RabbitMQ and other 3rd party libraries that use the AMQP style approach. Consistency is key.
  • postal.js is still young enough for this to not be a major disruption.

The plan:

  • Starting with postal v0.6.5, postal will include the AMQP style bindings resolver as something that can be opted into. It will still use the current implementation by default.
  • No later than postal v0.7.0, postal will ship with the AMQP style bindings resolver on by default, with the old version available to opt into for backwards compatibility.

Concerns? Please discuss!

@ifandelse
Copy link
Author

ifandelse commented May 25, 2012

Ok, so I'm tagging a few people to give them a chance to weigh in.... @nicholascloud, @arobson, @jaredfaris, @rauhryan, @davojan, @kevinswiber

@arobson
Copy link

arobson commented May 25, 2012

I like it. I think whole 'term' matching leads to better predictability in terms of matching topics. It's very cool that you will include different resolvers though. Everyone wins.

@webpro
Copy link

webpro commented May 25, 2012

+1

But isn't "#.Home" supposed to also match "Home"? The dot is a separator.

Example: *.stock.# matches the routing keys usd.stock and eur.stock.db but not stock.nasdaq.

@TravisTheTechie
Copy link

TravisTheTechie commented May 25, 2012

We don't use any wildcards in topic bindings currently, so I think @jaredfaris & I are set.

@jaredfaris
Copy link

jaredfaris commented May 25, 2012

I think in AMQP a # can substitute for 0+ words right? So I think @webpro is right that #.Home will match Home.

Otherwise I'm cool with this since it's more consistent with what everyone else is doing.

@ifandelse
Copy link
Author

ifandelse commented May 25, 2012

@webpro and @jaredfaris - you are both quite right, sorry about that. That'll teach me to work late yet again. Updating the gist now.

@jaredfaris
Copy link

jaredfaris commented May 25, 2012

That'll teach you to ask for feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment