#3022 closed defect (fixed)
[PATCH] Split rating from lobby bot into another
Reported by: | leper | Owned by: | scythetwirler |
---|---|---|---|
Priority: | Should Have | Milestone: | Alpha 21 |
Component: | Multiplayer lobby | Keywords: | patch |
Cc: | scythetwirler | Patch: |
Description
The rating functionality should be split from the bot into another, so that enabling/disabling/changing the rating system can be done independently of the main bot match making functionality.
(Also the rating system should be profiled and improved as it is slow with user numbers > 40)
Attachments (3)
Change History (17)
comment:1 by , 8 years ago
follow-up: 3 comment:2 by , 8 years ago
Locking ourself to a specific XMPP server is a bad idea. A nicer solution would be to use the Publisher-Subscriber XEP-60. But none of this is in the scope of this ticket which is simply about having two different bots running, which isn't a huge configuration overhead since nearly all of that is automated already.
follow-up: 4 comment:3 by , 8 years ago
Replying to leper:
Locking ourself to a specific XMPP server is a bad idea. A nicer solution would be to use the Publisher-Subscriber XEP-60. But none of this is in the scope of this ticket which is simply about having two different bots running, which isn't a huge configuration overhead since nearly all of that is automated already.
I'm having difficultly seeing why developing for a specifically for ejabberd is an issue. Our system already would be entirely broken without the ejabberd module and ejabberd supports every major platform. Also, I see no signs of ejabberd going away. It's the most widely used XMPP server in the world and is very actively developed.
In the case that someone wants to use a different server, they could use the old Python bot or use ejabberd as a remote service provider. The bot is relatively simple, so it could even be re-written from scratch for a different server.
In my opinion, this proposed approach is more scalable and moves towards getting rid of the SleekXMPP dependency (as SleekXMPP is no longer actively developed and behaves poorly with SQLAlchemy). I will look into using XEP-60 with this approach, as that sounds like a nice solution.
comment:4 by , 8 years ago
Replying to Josh:
I'm having difficultly seeing why developing for a specifically for ejabberd is an issue. Our system already would be entirely broken without the ejabberd module and ejabberd supports every major platform. Also, I see no signs of ejabberd going away. It's the most widely used XMPP server in the world and is very actively developed.
Lock in is always an issue, whether it is one now is not the point. It might end up being an issue in the future and the current module is quite minimal in what it needs to do, so the needed porting work when switching is kept to a minimum.
In the case that someone wants to use a different server, they could use the old Python bot or use ejabberd as a remote service provider. The bot is relatively simple, so it could even be re-written from scratch for a different server.
Which will not be maintained anymore, and someone will change the protocol so that this is not a solution. Having to rewrite things just because we don't think about maintainability when making changes seems like a bad trade-off.
In my opinion, this proposed approach is more scalable and moves towards getting rid of the SleekXMPP dependency (as SleekXMPP is no longer actively developed and behaves poorly with SQLAlchemy). I will look into using XEP-60 with this approach, as that sounds like a nice solution.
Then we should switch to something that is maintained. (And also switch away from using an ORM mapper when we do not need one since that is a solution in search of a problem in the bot. It likely isn't any more scalable since we'd need to run that module on each ejabberd instance (which is how one scales XMPP) and such would fragment the gamelist. As far as I can see using pubsub would alleviate this scaling issue, but as said that is not the point of this ticket, which is making sure that we can iterate the rating bot independently from the main functionality of the lobby.
comment:5 by , 8 years ago
Milestone: | Backlog → Alpha 20 |
---|---|
Owner: | changed from | to
Status: | new → assigned |
by , 8 years ago
Attachment: | LobbyBotSplit.patch added |
---|
comment:6 by , 8 years ago
Keywords: | patch review added |
---|---|
Summary: | Split rating from lobby bot into another → [PATCH] Split rating from lobby bot into another |
by , 8 years ago
Attachment: | LobbyBotSplitv2.patch added |
---|
follow-up: 8 comment:7 by , 8 years ago
Milestone: | Alpha 20 → Alpha 21 |
---|
Can be committed anytime, even between releases.
comment:8 by , 8 years ago
Keywords: | rfc added; review removed |
---|
Replying to scythetwirler:
Can be committed anytime, even between releases.
Was applied but for some reason it crashes every now and then since some ejabberd update or something
http://irclogs.wildfiregames.com/2016-05-15-QuakeNet-%230ad-dev.log
Moving it to the rfc queue
comment:10 by , 8 years ago
Keywords: | rfc removed |
---|
follow-up: 13 comment:11 by , 8 years ago
Replying to scythetwirler:
In 18609:
Thanks for the patch! I only see the reorganization of the main bot here. Could you please point me to the new ratings bot?
I am still working on some alternative implementations, but this should make my work easier. Ideally we can implement a basic XMPP pub/sub service for the gamelist, and have separate high performance code for ratings.
comment:13 by , 8 years ago
Replying to Josh:
Replying to scythetwirler:
In 18609:
Thanks for the patch! I only see the reorganization of the main bot here. Could you please point me to the new ratings bot?
I am still working on some alternative implementations, but this should make my work easier. Ideally we can implement a basic XMPP pub/sub service for the gamelist, and have separate high performance code for ratings.
See #4203.
I've been making good progress on this. To help minimize our dependencies and reduce the required configuration, I've wrapped up all the gamelist management into a new ejabberd module which replaces the old one. It dynamically intercepts gamelist stanzas from any channel and will eventually spawn a new handler for each channel (at the moment, all the channels are handled by one instance). I'm considering removing the changestate message type, as it's job could be done by a register message.
The current todo list is: