Support Parameterized Message Parsing

[hupili]

Current way of Message parsing:

• Platform class invoke self.Message, which is assigned as a special message class derived from Message.
• If you want to customize the behaviour of Message passing, you can derive the platform and its corresponding message class.

Here is a use case where the above way is not enough. RSS feeds are too heterogeneous. Some of the feeds do not include timezone suffix. In order to parse a correct time, we must add this suffix according to user's knowledge. In current implementation, platform class and message class are isolated. There is no way to pass this information.

[hupili]

A sample channel.json:

[
  {
    "url": "http://www.people.com.cn/rss/politics.xml", 
    "platform": "RSSSummary", 
    "__other__info": {
      "text": "\u56fd\u5185\u65b0\u95fb", 
      "html_url": "http://politics.people.com.cn"
    }, 
    "open": "yes", 
    "channel_name": "ch21. \u56fd\u5185\u65b0\u95fb",
    "message":{
      "timezone_correction": " +08:00"
    }
  }
]

The message dict will be passed to Message class. parse can refer to the message parsing parameters in self.conf or ignore it. This way is backward compatible.

[hupili]

Note one failed trial:

• Put the conf in message class as class attribute (not object attribute)
• In __init__ of the platform class, rewrite the conf according to channel.json.

This method is potentially more resource preserving. One data field is saved. One parameter passing is saved on each construction call of Message.

There are two difficulties:

• The initialization order of Python is not flexible, e.g. supporting "before", "in" and "after" so that class initialization is properly stacked. This support is not mandatory. We can still implement the function here but sacrifice some elegance.
• deepcopy does not effect on class. Once you rewrite config of the Message, all other channels of the same type is affected. I thought of using type to dynamically generate (copy) the class and rewrite configs, like this. I just doubt it won't work with pickle. pickle only works with toplevel classes ( https://github.com/hupili/snsapi/issues/28 ). Have not tried. Just doubt. If someone tried, please tell me.

Anyway, I would return to the plain implementation. The overhead incurred by this upgrade should be acceptable.