14396c3e32
In the next commit we're going to change what the
server sends for the following:
- page_params
- server responses to /json/users/me/presence
We will **not** yet be changing the format of the data
that we get in events when users update their presence.
It's also just a bit in flux what our final formats
will be for various presence payloads, and different
optimizations may lead us to use different data
structures in different payloads.
So for now we decouple these two things:
raw_info: this is intended to represent a
snapshot of the latest data from the
server, including some data like
timestamps that are only used
in downstream calculations and not
user-facing
exports.presence_info: this is calculated
info for modules like buddy_data that
just need to know active vs. idle and
last_active_date
Another change that happens here is we rename
set_info_for_user to update_info_for_event,
which just makes it clear that the function
expects data in the "event" format (as opposed
to the format for page_params or server
responses).
As of now keeping the intermediate raw_info data
around feels slightly awkward, because we just
immediately calculate presence_info for any kind
of update. This may be sorta surprising if you
just skim the code and see the various timeout
constants. You would think we might be automatically
expiring "active" statuses in the client due to
the simple passage of time, but in fact the precise
places we do this are all triggered by new data
from the server and we re-calculate statuses
immediately.
(There are indirect ways that clients
have timing logic, since they ask the
server for new data at various intervals, but a
smarter client could simply expire users on its
own, or at least with a more efficient transfer
of info between it and the server. One of
the thing that complicates client-side logic
is that server and client clocks may be out
of sync. Also, it's not inherently super expensive
to get updates from the server.)
|
||
|---|---|---|
| .circleci | ||
| .github | ||
| .tx | ||
| analytics | ||
| confirmation | ||
| corporate | ||
| docs | ||
| frontend_tests | ||
| locale | ||
| pgroonga | ||
| puppet | ||
| requirements | ||
| scripts | ||
| static | ||
| stubs | ||
| templates | ||
| tools | ||
| zerver | ||
| zilencer | ||
| zproject | ||
| zthumbor | ||
| .browserslistrc | ||
| .codecov.yml | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.json | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlint | ||
| .isort.cfg | ||
| .npmignore | ||
| .stylelintrc | ||
| .travis.yml | ||
| .yarnrc | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Dockerfile-postgresql | ||
| LICENSE | ||
| NOTICE | ||
| README.md | ||
| Vagrantfile | ||
| babel.config.js | ||
| manage.py | ||
| mypy.ini | ||
| package.json | ||
| postcss.config.js | ||
| tsconfig.json | ||
| version.py | ||
| yarn.lock | ||
README.md
Zulip overview
Zulip is a powerful, open source group chat application that combines the immediacy of real-time chat with the productivity benefits of threaded conversations. Zulip is used by open source projects, Fortune 500 companies, large standards bodies, and others who need a real-time chat system that allows users to easily process hundreds or thousands of messages a day. With over 500 contributors merging over 500 commits a month, Zulip is also the largest and fastest growing open source group chat project.
Getting started
Click on the appropriate link below. If nothing seems to apply, join us on the Zulip community server and tell us what's up!
You might be interested in:
-
Contributing code. Check out our guide for new contributors to get started. Zulip prides itself on maintaining a clean and well-tested codebase, and a stock of hundreds of beginner-friendly issues.
-
Contributing non-code. Report an issue, translate Zulip into your language, write for the Zulip blog, or give us feedback. We would love to hear from you, even if you're just trying the product out.
-
Supporting Zulip. Advocate for your organization to use Zulip, write a review in the mobile app stores, or upvote Zulip on product comparison sites.
-
Checking Zulip out. The best way to see Zulip in action is to drop by the Zulip community server. We also recommend reading Zulip for open source, Zulip for companies, or Zulip for working groups and part time communities.
-
Running a Zulip server. Use a preconfigured Digital Ocean droplet, install Zulip directly, or use Zulip's experimental Docker image. Commercial support is available; see https://zulipchat.com/plans for details.
-
Using Zulip without setting up a server. https://zulipchat.com offers free and commercial hosting.
-
Applying for a Zulip internship. Zulip runs internship programs with Outreachy, Google Summer of Code, and the MIT Externship program. Zulip also participates in Google Code-In. More information is available here.
You may also be interested in reading our blog or following us on twitter. Zulip is distributed under the Apache 2.0 license.