Guide to new plugins

Common Methods in SNSAPI's Abstraction

• auth: do authorization (e.g. via OAuth) or authentication (e.g. login Email).
• need_auth: Whether this platform requires two-stage authorization. See SNSBase.need_auth's comments for more info.
• expire_after: return the seconds before expiration of stored token. >0 for the relative seconds from now; =0 means that token has already expired (regardless how long it has expired); =-1 means this platform does not have token expiration issue (e.g. RSS, Email). SNSBase.is_expired and SNSBase.is_authed will invoke expire_after. Please keep them in the framework and only implement expire_after.
• [optional] home_timeline
• [optional] update
• [optional] reply
• [optional] forward

Although the last four methods are optional, you'd better implement as many as possible so as to enable more coherent operation of SNSAPI platforms. There may not be equivalent operations in all platforms. Please try to semantically cast their operations to those SNS primitives.

Message Class

You should derive from snstype.Message and implement the parse method. In the initialization of the Message object, we have put data in raw (given by clients). The parse method translate self.raw and store the result in self.parsed directly.

Please see the doc on Message class for the detailed description of self.parsed.

Token

self.token stores the information used to access a platform after authorization/ authentication. The basic structure is:

{
  "access_token": "????", 
  "expires_in": 1380345864, 
  ...
}

There can be more field depending on the platform. See those files under .save for the detailed structure of each platform.

expires_in is the epoch time (since 1970) when this token expires. Some platforms returns a relative time interval. You should change it in order to expose unified view to upper layers.

Note that not all platforms have token but they may have the equivalent data. Please put them in token so that users do not have to re-auth every time.

Test Approaches

Three types of tests:

• Use SNSPocket as the Service Access Point (SAP) of SNSAPI and see whether those batch operations are good. See the example on the CN Homepage. Please also invoke other methods.
• [optional] A module level test (demo) in your ifmain block. See sina.py for an example. This test may or may not require the intervention of human.
• [optional] Add UT in tests for automatic parts. For example, message parsing does not require the intervention of users. You can setup the test hubs yourself and make sure the parse is not broken by other people in upgrade process. See tests/test_renren.py for an example. Although optional, but strongly recommended.

Possible test points:

• Go through the auth flow (maybe with different auth_info configurations).
• The four social networking primitives home_timeline, update, reply, forward. See whether the response is as expected.
• Exit and re-launch Pocket. See whether saved token (if any) works.