github.com/diamondburned/cchat
Package cchat is a set of stabilized interfaces for cchat implementations, joining the backend and frontend together. Almost anything in the backend comes with an ID. For example, a Server must have an ID, or a Session must have a user ID. The backend is required to guarantee that IDs are somehow unique. This should already be the case for most chat services; for example, Discord provides IDs for guilds, channels, members, and more. The only time that the backend should not guarantee ID uniqueness is across Sessions, because it doesn't make sense to do so. In this case, the frontend should guarantee uniqueness instead, either by discarding duplicated items, overriding them, or anything reasonable and explicit. Methods implemented by the backend that have frontend containers as arguments can do IO. Frontends must NOT rely on individual backend states and should always assume that they will block. Methods that do not return an error must NOT do any IO to prevent blocking the main thread. As such, ID() and Name() must never do any IO. Methods that do return an error may do IO, but they should be documented per method. Backend implementations have certain conditions that should be adhered to: Note: IO in most cases usually refer to networking, but they should files and anything that is blocking, such as mutexes or semaphores. Note: As mentioned above, contexts are optional for both the frontend and backend. The frontend may use it for cancellation, and the backend may ignore it. Some interfaces can be extended. Interfaces that are extendable will have methods starting with "As" and returns another interface type. The implementation may or may not return the same struct as the interface, but the caller should not have to type assert it to a struct. They can also return nil, which should indicate the backend that the feature is not implemented. To avoid confusing, when said "A implements B," it is mostly assumed that A has a method named "AsB." It does not mean that A can be type-asserted to B. For future references, these "As" methods will be called asserter methods. Note: Backends must not do IO in the "As" methods. Most of the time, it should only conditionally check the local state and return value or nil. Below is an example of checking for an extended interface. Frontend contains all interfaces that a frontend can or must implement. The backend may call these methods any time from any goroutine. Thus, they should be thread-safe. They should also not block the call by doing so, as backends may call these methods in its own main thread. It is worth pointing out that frontend container interfaces will not have an error handling API, as frontends can do that themselves. Errors returned by backend methods will be errors from the backend itself and never the frontend errors.
Readme
A set of stabilized interfaces for cchat implementations, joining the backend and frontend together.
Refer to the GoDoc for interfaces and documentations.
The following sections contain known cchat implementations. PRs are welcomed for more implementations to be added here.
FAQs
Package cchat is a set of stabilized interfaces for cchat implementations, joining the backend and frontend together. Almost anything in the backend comes with an ID. For example, a Server must have an ID, or a Session must have a user ID. The backend is required to guarantee that IDs are somehow unique. This should already be the case for most chat services; for example, Discord provides IDs for guilds, channels, members, and more. The only time that the backend should not guarantee ID uniqueness is across Sessions, because it doesn't make sense to do so. In this case, the frontend should guarantee uniqueness instead, either by discarding duplicated items, overriding them, or anything reasonable and explicit. Methods implemented by the backend that have frontend containers as arguments can do IO. Frontends must NOT rely on individual backend states and should always assume that they will block. Methods that do not return an error must NOT do any IO to prevent blocking the main thread. As such, ID() and Name() must never do any IO. Methods that do return an error may do IO, but they should be documented per method. Backend implementations have certain conditions that should be adhered to: Note: IO in most cases usually refer to networking, but they should files and anything that is blocking, such as mutexes or semaphores. Note: As mentioned above, contexts are optional for both the frontend and backend. The frontend may use it for cancellation, and the backend may ignore it. Some interfaces can be extended. Interfaces that are extendable will have methods starting with "As" and returns another interface type. The implementation may or may not return the same struct as the interface, but the caller should not have to type assert it to a struct. They can also return nil, which should indicate the backend that the feature is not implemented. To avoid confusing, when said "A implements B," it is mostly assumed that A has a method named "AsB." It does not mean that A can be type-asserted to B. For future references, these "As" methods will be called asserter methods. Note: Backends must not do IO in the "As" methods. Most of the time, it should only conditionally check the local state and return value or nil. Below is an example of checking for an extended interface. Frontend contains all interfaces that a frontend can or must implement. The backend may call these methods any time from any goroutine. Thus, they should be thread-safe. They should also not block the call by doing so, as backends may call these methods in its own main thread. It is worth pointing out that frontend container interfaces will not have an error handling API, as frontends can do that themselves. Errors returned by backend methods will be errors from the backend itself and never the frontend errors.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
A hospital in Mobile, Alabama, agreed to a settlement in a landmark ransomware death lawsuit, but is now reportedly reconsidering the agreement and refusing to pay.
Security News
A new report explores how advancements in LLMs are enhancing cyber threats, including polymorphic malware, personalized spearphishing, and the risk of hijacking customer service bots.
Security News
ESLint has approved an RFC that adds support for TypeScript configuration files, which is aimed at improving the developer experience and recognizing changes in the evolving JavaScript ecosystem.
