Bot design about stargazer-reborn HOT 2 OPEN

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?

from stargazer-reborn.

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

from stargazer-reborn.