Skip to content
This repository has been archived by the owner on Jul 24, 2020. It is now read-only.

[General Architectural Ideas] #5

Open
RickvanLoo opened this issue Feb 14, 2016 · 1 comment
Open

[General Architectural Ideas] #5

RickvanLoo opened this issue Feb 14, 2016 · 1 comment
Milestone

Comments

@RickvanLoo
Copy link
Owner

  • It might be cool to have a server daemon that receives all Discord messages, parses them and sends them to multiple attached clients. This way it would be possible to have multiple Discord Channels open and it would still be lightweight.
  • When working with external C Libraries, and going to a Daemon-Window structure it wouldn't be too far-fetched to just write the client in C since it only handles input/output to the terminal.
@RickvanLoo RickvanLoo added this to the future milestone Feb 14, 2016
@RickvanLoo RickvanLoo changed the title Server - Client architecture [General Architectural Ideas] Feb 15, 2016
@RickvanLoo
Copy link
Owner Author

Message handling is currently quite dumb, it receives, checks and prints. If we want to have editing/deleting options or respect those options from the users of the official client we have to manipulate the output quite heavily. There is currently no way to check when the message has been posted and on which line it is when we are talking about an old one. So when a MessageChange or MessageDelete event comes in there is no way to check which line needs to be altered. There is currently also no written way to do this.

I suggest using a kind of in-memory database structure where messages are linked to an integer. It will only keep a configurable amount (default probably 20-50) in memory, and manipulate these.
This needs forking and rewriting of the chzyer/readline#26 lib, or writing an alternative solution that is based on the same kind of method log.Setoutput() @chzyer uses.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant