Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve terminology #525

Open
eopo opened this issue Jun 25, 2022 · 2 comments
Open

Improve terminology #525

eopo opened this issue Jun 25, 2022 · 2 comments

Comments

@eopo
Copy link
Collaborator

eopo commented Jun 25, 2022

Is your feature request related to a problem? Please describe.
Both in the source code and in the documentation, some terms are used ambiguously, while other things are described with multiple terms. Examples would be "message", which refers to both a telegram and its content. The object that links a RIC with information about its representation is called both "capcode" and "alias", although both terms have different meanings.

Describe the solution you'd like
We should disambiguate the terms while staying as close as possible to the specification of the respective protocols. Problems arise because POCSAG and FLEX sometimes use different terminology for identical properties. In Europe, the term "RIC" is commonly used under POCSAG to designate the address of a pager, although "cap code" is also used in the standard. A consensus must therefore be found here.

@geelongmicrosoldering
Copy link
Collaborator

I've noticed some things like this. Terms that dont align. It happens in code too. Actually i noticed the other day in the message api, the key for epoch time could be "timestamp" or "datetime" depending on if its a get request, or a post.

@eopo
Copy link
Collaborator Author

eopo commented Jun 25, 2022

Yeah, just things that happen when many people work on many parts of code over a long period of time.
It will be a breaking change, but I guess it is worth it. We should make some definitions of what's called in the Documentation and everything added should adhere to that.

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

No branches or pull requests

2 participants