You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When working on specific integrations (notably, those that do not /sync) it's common practice to pull in state for a room via the /state API. The reason for doing so is that often you want several state events, and events of the same type. There isn't another way currently to fetch many state events of the same type, as the only APIs that exist are /state, and /state/{eventType}/{stateKey}.
Therefore, often a lot of time is wasted gathering the entire state of the room and sending it along to the integration whereby most of it (e.g. members) are thrown out immediately. Performance could be improved on both sides by allowing a mechanism to filter for the state you care about instead.
For the example of hookshot, we have many state event types that we support (uk.half-shot.hookshot.github.*) but also many that we don't care about. Often the startup loop consists of fetching all state for a room, and then determining it's room type(s) by the events that get returned. A lot of time could be saved by specifying a filter here.
The text was updated successfully, but these errors were encountered:
For https://spec.matrix.org/latest/client-server-api/#get_matrixclientv3roomsroomidstate
When working on specific integrations (notably, those that do not /sync) it's common practice to pull in state for a room via the /state API. The reason for doing so is that often you want several state events, and events of the same type. There isn't another way currently to fetch many state events of the same type, as the only APIs that exist are
/state
, and/state/{eventType}/{stateKey}
.Therefore, often a lot of time is wasted gathering the entire state of the room and sending it along to the integration whereby most of it (e.g. members) are thrown out immediately. Performance could be improved on both sides by allowing a mechanism to filter for the state you care about instead.
For the example of hookshot, we have many state event types that we support (
uk.half-shot.hookshot.github.*
) but also many that we don't care about. Often the startup loop consists of fetching all state for a room, and then determining it's room type(s) by the events that get returned. A lot of time could be saved by specifying a filter here.The text was updated successfully, but these errors were encountered: