The next release of reliable-msg will introduce two changes to the API. I hope it won’t cause much of a problem.
The first change is in naming. Messages will still have identifiers and headers, but the meat of the message is now the payload. This just removes confusion in the API and documentation. Retrieving a message will return an object with the method payload, and the misnamed method message will be deprecated.
The second change deals with the payload type. The next release will enforce the payload to be a string and will no longer accept arbitrary Ruby objects. There are two reasons for this change.
Using Ruby objects limit the protocol to DRb, since we’re passing around data that only Ruby understands. I want to add HTTP support, be able to exchange messages with non-Ruby applications, maybe use stomp. I can do that with strings.
Second, to retrieve a binary message the code must be able to unpack it. There are some cases where the code handles the message but doesn’t act on its content: move it around, archive it, etc. If the object needs to be unpacked, you need all the Ruby classes used when creating the object, not just the base Ruby library, which makes it impossible to write generic utilities.
Quick Workaround Well, may not a workaround, because it lets you do more, if you choose to. Say you want to sends some arbitrary Ruby object asynchronously. You need to marshal and unmarshal it yourself, but Ruby makes that dead simple. To send the message:
queue.put Marshal::dump(object)
to extract the message
msg = queue.get
object = Marshal::load(msg.payload)
And if you want you can also replace Marshal with YAML and dump/load into a YAML document that’s more portable, or use XML, or even JSON.
|
Start New Thread
Change to message payload in reliable-msg [ reply ]