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

Spec lazy_load_members and include_redundant_members #1758

Merged
merged 2 commits into from Dec 24, 2018

Conversation

Projects
None yet
4 participants
@KitsuneRal
Copy link
Contributor

KitsuneRal commented Dec 15, 2018

This is an implementation of #1227 - that better (than #1287) matches the current Synapse implementation.

Spec lazy_load_members and include_redundant_members
Signed-off-by: Alexey Rusakov <Alexey.Rusakov@pm.me>
@KitsuneRal

This comment has been minimized.

Copy link
Contributor

KitsuneRal commented Dec 15, 2018

libQMatrixClient master uses this reading in its lazy-loading implementation.

@turt2live turt2live requested review from turt2live and matrix-org/spec-core-team and removed request for turt2live Dec 17, 2018

@turt2live

This comment has been minimized.

Copy link
Member

turt2live commented Dec 17, 2018

Ideally someone like @ara4n who knows what the implementation actually does would be best to review this.

@ara4n

This comment has been minimized.

Copy link
Member

ara4n commented Dec 17, 2018

oh, awesome - thanks @KitsuneRal. will review

@KitsuneRal

This comment has been minimized.

Copy link
Contributor

KitsuneRal commented Dec 18, 2018

It just occurred to me that we probably will need a separate section in the spec that explains how lazy-loading works from clients' standpoint (mostly reworded sections of https://docs.google.com/document/d/11yn-mAkYll10RJpN0mkYEVqraTbU3U4eQx9MNrzqX1U/edit#heading=h.q5mz9uiufb2g). This also covers MSC688 and MSC1337 though. I see 3 ways to do it:

  1. Put this textual explanation to either of the MSCs we already have here, assuming that room summaries and extension of /members will shortly land in spec too.
  2. Turn, e.g., this PR into a self-contained spec PR on lazy-loading functionality, including all parts (note that we still don't have a spec PR on MSC688).
  3. After MSC1227, MSC688 and MSC1337 land in the repo as YAML files, submit one more spec PR with the text.
    Option 2 look best to me (because of being self-contained) but it may turn a bit too bulky and harder to review in one go (and also MSC1337 brings its own value regardless of lazy-loading) . The next preferable option is probably 3 because then we can land things in the spec in a fine-grained, easier consumed and probably better controlled manner.
@richvdh
Copy link
Member

richvdh left a comment

This generally LGTM, though it seems we've lost a paragraph from https://github.com/matrix-org/matrix-doc/pull/1287/files#diff-0365f42e14699ef8c27554ce3860f18fR137 which seemed useful?

@richvdh

This comment has been minimized.

Copy link
Member

richvdh commented Dec 18, 2018

It just occurred to me that we probably will need a separate section in the spec

Yes we do, though now that we have this PR (and #1287...), let's get it landed. #1287 is a good demonstration of how PRs can get stuck for 6 months waiting for the last 10%.

Also, as I note on #1337, that's still in proposal stage, so I certainly wouldn't advise rolling that in here right now.

@KitsuneRal

This comment has been minimized.

Copy link
Contributor

KitsuneRal commented Dec 23, 2018

@richvdh, thanks for spotting, I will add the missing NB here shortly. So are you after option 1 or option 3 in your second comment?

@richvdh

This comment has been minimized.

Copy link
Member

richvdh commented Dec 24, 2018

As I see it the remaining work here is:

  1. document room summaries MSC688
  2. write some words giving an overview of how lazy-loading works

I don't have strong feelings about whether that work is done as one or two PRs.

(separately we need to deal with #1337)

@richvdh
Copy link
Member

richvdh left a comment

lgtm

@richvdh richvdh merged commit 8f1291a into matrix-org:master Dec 24, 2018

7 checks passed

ci/circleci: build-dev-scripts Your tests passed on CircleCI!
Details
ci/circleci: build-docs Your tests passed on CircleCI!
Details
ci/circleci: build-swagger Your tests passed on CircleCI!
Details
ci/circleci: check-docs Your tests passed on CircleCI!
Details
ci/circleci: validate-docs Your tests passed on CircleCI!
Details
docs Click details to preview the HTML documentation.
Details
swagger Click to preview the swagger build.
Details

@KitsuneRal KitsuneRal deleted the QMatrixClient:kitsune/lazy-loading branch Dec 24, 2018

@ara4n

This comment has been minimized.

Copy link
Member

ara4n commented Dec 24, 2018

So, i only just got to review this (sorry for lag). Whilst it correctly describes the original intention of LL, it should probably be reworded slightly to reflect the current reality, which is that LL only kicks in for initial sync if enabled. Gappy incremental syncs currently do include membership changes which happened during the gap, otherwise a client who wished to track the full membership of the room (for tab-complete, typing notifs etc) would have to do a full /members sync after every incremental sync... which ends up being worse than non-LL behaviour. The 'correct' solution is to provide an incremental dialect of /members, but that doesn't exist yet. See vector-im/riot-web#7211 (comment) for more details.

Also, we need to be explicit that you see yourself in LL members (even if you're not speaking in the room).

I guess these should go in a separate PR?

@KitsuneRal

This comment has been minimized.

Copy link
Contributor

KitsuneRal commented Dec 25, 2018

Given that this is already merged, any amendment can only happen in a separate PR. Frankly, I consider the above-mentioned a feature rather than a problem. I agree it should be explicitly noted though; will come back with another PR soonish.

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