serializable_hash: Jobs should partially define how to as serialize and de-serialize themselves

[jacobo]

(based on feedback from #9910)

Problem I'm trying to solve:

Users of Rails Q API expect the Q system to be able to serialize and de-serialize the jobs they enQ. If it's unable to do so, it should complain about it with an exact reason, at the time of enQ.

My take:

This problem can't easily be solved exclusively by the framework. Any attempt to do so fully would likely lead to a leaky abstraction wherein Job authors end up digging in to the guts of such an implementation.

Instead, a simple and minimal contract should exist between Job objects and the framework responsible for enQ-ing and running them.

1. a run method
2. a serializable_hash method
3. a from_serializable_hash method

Additionally:

Backend job systems should have a choice on how to serialize jobs. It's fine for Marshal to be the default in Rails, but it's unnecessarily restricting to impose this requirement on all integrators.

[jeremy]

Hey @jacobo - there are going to be deeper, more fundamental changes to queueing. I'm thrilled that you're pitching in, but this line of development is a dead end, I'm afraid!

[jacobo]

@jeremy - Are there any other "lines" or approaches you might be able to suggest?

Would you be open to seeing a from-scratch rails 4 Q implementation based on existing resQ or sidekiq conventions?

[steveklabnik]

We're going back to the drawing board for the API, and it's (tentatively) slated for 4.1.

If you'd like to work on this kind of stuff, we (the Resque team) would love to have you.