Add mobile support for new user_avatar_url_field_optional client capability
#4157
Assignees
Labels
Comments
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Aug 19, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. Fixes: zulip#4157
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Aug 19, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. Fixes: zulip#4157
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Aug 24, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. Some of the boilerplate in the new FallbackAvatarURL class is due to a performance optimization [2] based on an observed ~1s added to the rehydrate time on CZO when URL objects are constructed, vs. about 200ms (and maybe a bit more in the upper tail) when they aren't. During rehydration, we don't need to expensively construct URL objects to validate raw URL strings, as long as we do so at the edge when we receive them from the network. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. [2] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/user_avatar_url_field_optional/near/993660 Fixes: zulip#4157
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 22, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. Some of the boilerplate in the new FallbackAvatarURL class is due to a performance optimization [2] based on an observed ~1s added to the rehydrate time on CZO when URL objects are constructed, vs. about 200ms (and maybe a bit more in the upper tail) when they aren't. During rehydration, we don't need to expensively construct URL objects to validate raw URL strings, as long as we do so at the edge when we receive them from the network. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. [2] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/user_avatar_url_field_optional/near/993660 Fixes: zulip#4157
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 22, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. Some of the boilerplate in the new FallbackAvatarURL class is due to a performance optimization [2] based on an observed ~1s added to the rehydrate time on CZO when URL objects are constructed, vs. about 200ms (and maybe a bit more in the upper tail) when they aren't. During rehydration, we don't need to expensively construct URL objects to validate raw URL strings, as long as we do so at the edge when we receive them from the network. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. [2] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/user_avatar_url_field_optional/near/993660 Fixes: zulip#4157
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Oct 26, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. Some of the boilerplate in the new FallbackAvatarURL class is due to a performance optimization [2] based on an observed ~1s added to the rehydrate time on CZO when URL objects are constructed, vs. about 200ms (and maybe a bit more in the upper tail) when they aren't. During rehydration, we don't need to expensively construct URL objects to validate raw URL strings, as long as we do so at the edge when we receive them from the network. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. [2] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/user_avatar_url_field_optional/near/993660 Fixes: zulip#4157
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Oct 28, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. Some of the boilerplate in the new FallbackAvatarURL class is due to a performance optimization [2] based on an observed ~1s added to the rehydrate time on CZO when URL objects are constructed, vs. about 200ms (and maybe a bit more in the upper tail) when they aren't. During rehydration, we don't need to expensively construct URL objects to validate raw URL strings, as long as we do so at the edge when we receive them from the network. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. [2] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/user_avatar_url_field_optional/near/993660 Fixes: zulip#4157
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Nov 3, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. Some of the boilerplate in the new FallbackAvatarURL class is due to a performance optimization [2] based on an observed ~1s added to the rehydrate time on CZO when URL objects are constructed, vs. about 200ms (and maybe a bit more in the upper tail) when they aren't. During rehydration, we don't need to expensively construct URL objects to validate raw URL strings, as long as we do so at the edge when we receive them from the network. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. [2] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/user_avatar_url_field_optional/near/993660 Fixes: zulip#4157
chrisbobbe
added a commit
that referenced
this issue
Nov 3, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. Some of the boilerplate in the new FallbackAvatarURL class is due to a performance optimization [2] based on an observed ~1s added to the rehydrate time on CZO when URL objects are constructed, vs. about 200ms (and maybe a bit more in the upper tail) when they aren't. During rehydration, we don't need to expensively construct URL objects to validate raw URL strings, as long as we do so at the edge when we receive them from the network. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. [2] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/user_avatar_url_field_optional/near/993660 Fixes: #4157
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Nov 23, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. Fixes: zulip#4157
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Dec 15, 2020
See the point on `user_avatar_url_field_optional` at https://zulipchat.com/api/register-queue. This will reduce the volume of data that will have to be sent in the `/register` response, which should speed up the initial load. Now, the server may choose, at its own discretion, to omit the `avatar_url` field for users in the `/register` response [1], and we'll handle it by using the `/avatar/{user_id}` endpoint. [1] As of the introduction of the client capability (Zulip 3.0, feature level 18), it makes this decision based on whether the user has been inactive for a long time (using the `long_term_idle` field), but this is an implementation detail and should be expected to change without notice. Fixes: zulip#4157
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To resolve zulip/zulip#15287, we're introducing a new client_capability that should allow the mobile app to have good performance when talking to servers with thousands of long-term-idle users (and email_address_visibility configured; that last bit being relevant mainly in that our previous attempt at solving this problem.
client_gravatarfeature works only with EMAIL_ADDRESS_VISIBILITY_EVERYONE), since the client needs real email addresses to compute gravatar hashes.One should be able to prototype today against zulip/zulip#15359; it should work aside from having the wrong capability name. I expect that to get cleaned up and this to merge in the next few days.
Tagging as a priority since this issue makes chat.zulip.org a lot slower to load on mobile.
The text was updated successfully, but these errors were encountered: