Unsubscribe

[wcyz666]

For sinaweibo. Advice wanted!

[hupili]

More design is needed. Finally, this goes as far as befriend and unfriend functions. Unsubscribing a message is strange. You basically want to unsubscribe a user and the user happen to posted a particular message. Towards this end, you need to design User and UserID object, as is in the case of Message and MesageID. When parsing Message, we no longer need username and userid field. Instead, we need to put User, which further contains UserID. This is a more unified way of presentation.

Current design/implementation is partial. If only for the purpose of hiding someone's message, I still think SNSRouter is the better place. You don't have to touch the user's data on original service providers. Instead, you flag unwanted users in SNSRouter's table. This has legitimate use case: sometimes you don't want to unfriend someone (maybe embarrassing because you're offline friends); you just want to hide his/her message.

[wcyz666]

Well, changing to User(I think "Owner" may be more appropriate here) means a major, or more precisely, a colossal change in the whole snsapi/snsrouter implementation. Given this change realized, the input parameter could be message.user. Admittedly it's clearer than merely message, but the price we paid to achieve may overwhelm what we gain since we can only add unsubscribe() (or blacklist()) to our current api.

I agree with you that unsubscribe() may be too radical and I suggest two rather moderate methods block()/unblock instead of unsubcribe(). block()/unblock() allows us to hide/show others' message but leaving relationship untouched. unsubcribe() should only be used as a symbol to show that two persons are done. But it's not a bad idea to remain unsubcribe().

[hupili]

Your first paragraph right explains why this (current) function had better be implemented in SNSRouter. The partial abstraction is OK to go to SNSRouter. In order to enter SNSAPI, we need more thorough design and collection of use cases. Application layer has more freedom in post-processing messages, e.g. hide one message or one category. In SNSRouter, this can even be softly realized via the ranking module. Finally, the block/ unblock functions (without intervention of provider side) are stateful. You need to remember those information somewhere. This is similar to the case of .liked field. Doing this as SNSrouter is OK because it already has permanent storage. Also, starting from SNSRouter (applications) gives you more time to validate the concept. If some pattern arise repeatedly, you know you need to abstract them somehow.