Bot design

[George-Miao]

Several issues.

• How will bot receive events, by MQ?
• Are bots going to interact with the DB that stores session info directly, or should it interact with API?
• If they do, should we make session related code into a separated submodule?
• If they don't, does that mean bots will not depend on mongodb, and we should also write a API client?

[George-Miao]

After discussion, our design decision is that:

• Bots will receive events from RabbitMQ
• Bots will interact with API, not DB.
• Therefore, an API client library is required.

Looks good? @PhotonQuantum

[George-Miao]

Update: This is no longer needed. According to benchmark, time consumption of the MongoDB fetch that does this is in an acceptable range for K < 300,000, where K is len(entities) * len(kinds) * len(users). In prodution we can also introduce a cache.

---

In order for the API and bots to distribute updates to corresponding subscribers, we will need an index. Currently, there's a type in the core submodule called EventFilter, which represents a user configuration about what they are interested in, thus what events they will be receiving. And that implies a mapping relationship from User to Events. However, with updates that are a stream of Events from MQ, this mapping relationship can bring a time complexity of O(u) on every update, where u is the number of users.

Thus, we shall introduce a new design, Index, where the relationship is {[Event] -> User[]}, derived from the existing event filter, which will be stored as user configuration. We can utilize multimap to accomplish this. Re-indexing is needed once in a while for this design and brings the drawback of delaying the user's update.

@PhotonQuantum any thoughts?