Ecosyste.ms: Packages

An open API service providing package, version and dependency metadata of many open source software ecosystems and registries.

Top 6.8% on proxy.golang.org
Top 2.8% dependent packages on proxy.golang.org
Top 3.5% dependent repos on proxy.golang.org

proxy.golang.org : 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.

Registry - Source - Documentation - JSON
purl: pkg:golang/github.com/diamondburned/cchat
License: ISC
Latest release: about 3 years ago
First release: about 4 years ago
Namespace: github.com/diamondburned
Dependent packages: 4
Dependent repositories: 2
Stars: 23 on GitHub
Forks: 1 on GitHub
See more repository details: repos.ecosyste.ms
Last synced: 21 days ago

    Loading...
    Readme
    Loading...