Restructure Status Class / Config Class

[hupili]

In the development of apps, pocket and cli, I find the current way of handling Status and Configs are not flexible.

Here's the proposal for Status class:

• Base on dict. Current attributes are stored in dict.
• Convert any field into: dict, list, unicode. (making sure it is json serialisable)
• Three levels of serialization:
  • Console output. through "str", "unicode". Only serialize the basic information, conforming to status output convention. This is intended for end user operating in console. Currently in use.
  • Interface output. Detailed and structured output. The format should be easy to parse since it is intended to other programmes waiting at the other end of the pipeline. All SNSAPI information is formatted (e.g. besides basic information shown on console, ID information is also there in case one want to reference a Status Object in another call). More details are to be designed. Different formats should be supported (driven by app demand).
  • Complete output. Sometimes, presented message is calculated from raw response json object. e.g. in the RSS channel, there is no the notion of "status" nor equivalence. We put author, title, link, date together to construct a "text" field so that it is compatible with all other components. Complete output will be the last source of all information. Make it there in case some application use it.

Configs (for each channel) has similar problem. Better to substitute

c.platform = xxxx

to

c.jsonconf["platform"]

This simplifies the config loading and saving process. Also easier to integrate crypto utility (easier to serialize). Or in the place we need serialization, one should do several:

s["xxxx"] = c.xxxx
s["yyyy"] = c.yyyy
...

[uxian]

Indeed, it will be more flexible to base on dict rather than object.
I think it's no need to substitue 'c.platform = xxxx' to 'c.jsonconf["platform"]'

Do you see the JsonObject in utile.py

class JsonObject(dict):
    '''
    general json object that can bind any fields but also act as a dict.
    '''
    def __getattr__(self, attr):
        return self[attr]

    def __setattr__(self, attr, value):
        self[attr] = value

We can restructure Status to this

class Status(dict):
    def __getattr__(self, attr):
        return self[attr]

    def __setattr__(self, attr, value):
        self[attr] = value

Then, there will be 2 ways to approach attribute

status.text
status['text']

[hupili]

@uxian

I saw the encapsulation of JsonObject() before. That trick is really convenient in accessing attributes! I just remember when I was developing something one month ago, there were some problems on this; So you see the JsonDict class in the latest branch... I can not repeat the experiment now....

It's worth to unify the internal interfaces. Passing that JsonObject seems a good choice. According to the current usage, I agree to basing Status on that JsonObject-like class. For channel configs, probably c.jsonconf["platform"] is still needed, where jsonconf is the JsonObject-like class. This is because channel can have other attributes but jsonconf is just the equivalent structure of those configs written in "channel.json". For Status, it's OK to make the full class a JsonObject; we need to serialize it as a whole in some use case.

[hupili]

This thread is done in latest dev branch, #23.

[hupili]

A phase out of L2/L3 serialization is proposed in #105