Just need to send messages into rooms now for a first cut to be done. Notable
improvements to make:
- We currently do 1 goroutine per service. This could be bad if we have lots of these things running around.
- We do not cache the response to RSS feeds. If we have 10 independent services on the same feed URL, we will
hit the URL 10 times. This is similar to how we currently do 1 webhook/service, so it's plausible that in
the future we will want to have some kind of generic caching layer.
- We don't send messages to Matrix yet. We need a `Clients` instance but can't get at one. There's only ever
one, so I wonder if we should global it like we do with `GetServiceDB()` for ease of use?
- The polling interval is divorced from the actual feed repoll time. Ideally we would schedule the goroutine
only when we need it, rather than checking frequently, determining we have nothing to do, and going back
to sleep.
* WIP: Initial Guggy
* Finish Guggy integration
* typo & send No GIF Found when GIF string empty
* unused function
* Unused import, HTTPS API and GIFs
* APIKey -> api_key
* Use api_key on the wire, APIKey in structs
`DefaultService` serves as a useful no-op service to cut down on bloat when
implementing new Services. This means we can add more methods more freely to
the interface of `Service` without bogging down the Service implementation.
`Poller` is an interface which contains a polling interval and a function to
invoke. This will be used for RSS feeds.
Implemented a stub `RSSService`.
Allows users to nuke their OAuth credentials. Currently this just does a database
`DELETE` as neither Github nor JIRA need you to hit any special `/logout` API.
Indirect this through a `NextBatchStore` type to get around circular dependencies
which are formed if you try to inline it in the `Sync()` while loop.
Fork out event handlers to separate functions in `Clients` to make gocyclo happy.
Add `UPDATE` query for `next_batch`.
Removing a repo entirely from a service will now remove the webhook in the
`PostRegister()` function. This function is still within the `configureService`
critical section to prevent another request for the same service racing with
the cleanup process.