* Split out notifying /sync requests and calculating sync responses
The logic for notifying /sync requests is about to get really
complicated as we optimise when to wake up requests, so split
out that code into a separate struct to isolate it and make
it easier to unit test.
This has the following known shortcomings:
- It doesn't handle missing events not in the from/to range.
- It doesn't order events in the timeline correctly.
- It doesn't handle invited/left rooms at all.
- There is no intelligent wakeup logic: events for Bob will wake up Alice's stream.
Currently the HTTP handlers are attached to an API mux which is created inside
Setup(). In the future, we'll want to split this out so a single mux can have
both sync and clientapi handlers attached to it.
This distinguishes them from tools like 'kafka-producer'
which are not required to run a dendrite server.
The prefix also groups together the dendrite binaries nicely
on `ls` as well as making it nicer to tab-complete.
This involves:
- Parsing the HTTP request
- Requesting auth events from the roomserver via the Query API
- Building the event
- Doing auth checks on the event
- Sending it to the roomserver input log
Previously, the error responses:
- were not valid matrix errors (no `errcode`)
- returned the `err.Error()` message which may contain sensitive information.
- did not get logged (at all, let alone set the level correctly).
Now the error responses:
- return valid matrix errors (`M_UNKNOWN`)
- return a generic "Internal Server Error" string
- get logged at `ERROR` level.
* Return the requested portions of current state in the query API
* Use Unique from github.com/matrix-org/util
* rewrite bulkSelectFilteredStateBlockEntries to use append for clarity
* Add test for stateKeyTupleSorter
* Replace current with a new StateEntryList rather than individually setting the fields
* Add method for calculating the room state after a list of events
* Fill out AddsState and RemovesState fields in the output event
* comment on return value
* Fix whitespace
* Clarify the meaning of LastEventIDSent
* Be more explicit on what the snapshot is
* Fix comments
* Comment on why we want the state after the previous events
* Start implementing a query API for go using net/rpc
* Use a conventional JSON POST API rather than go net/rpc
net/rpc doesn't automatically handle reconnecting and we have better
logging and metrics infrastructure for monitoring HTTP apis.
* Implement the query API and add it to the integration tests
* Increase the timeout, travis seems to be a bit slow
* Clarify that state events are the things that are not returned if they are not requested
* Add utility function for converting arrays of numeric event IDs to pq Int64Arrays
* Warn people against requesting empty state keys by accident
* Add integration tests for roomserver to travis
* Try setting the dist trusty to see if that helps with postgres
* Pretty print the test input JSON
* Add comment as to why we are using trusty
* Marshal and Unmarshal methods for roomserver input api
* Comments for why we don't json.marshal the InputRoomEvent directly
* More comments
* s/m.room.create/the first event/
Terse function names are used to make usage not stutter. For example:
```go
err := error.Forbidden("you shall not pass")
```
At the moment they are all the same fundamental `MatrixError` type. This will
be bad if we ever want to `switch` based on the kind of error. I'm hoping we
won't ever need to introspect into errors like this: ideally these errors would
be created purely for immediately being returned in an HTTP response.
`MatrixError` implements the `error` interface.
* Move partition offsets sql to a separate file
* Move event types sql to a separate file
* Move event state key sql to a separate file
* Move room sql to a separate file
* Move events sql to a separate file
* Move event json sql to a separate file
* Move state snapshot sql to a separate file
* Move state block sql to a separate file
* A kafkaesque room event consumer for the roomserver.
Implement the main input loop for the roomserver.
It will receive events from a kafkaesque event source and track
where it is in the stream.
It currently does nothing with the events it consumes.
