Skip to content
This repository has been archived by the owner on May 16, 2019. It is now read-only.

Store synced data #66

Open
7 of 8 tasks
turt2live opened this issue Mar 5, 2018 · 3 comments
Open
7 of 8 tasks

Store synced data #66

turt2live opened this issue Mar 5, 2018 · 3 comments
Assignees
Labels
enhancement New feature or request p3 Should be dealt with before p4
Milestone

Comments

@turt2live
Copy link
Owner

turt2live commented Mar 5, 2018

Checklist

  • Timeline events
  • Room state
  • Account data
  • Per-room account data
  • Read receipts (+co. - ephemeral events in the room)
  • Prune storage to 50 timeline events
  • Prune memory timeline to 150 events
  • Don't store leaves (unless they are needed)

Description

This includes a fairly major refactoring of how rooms/events are represented outside the services. It should also address issues like #64 and add in supporting framework for #54.

Much of this issue is for documentation purposes when/if the system needs to be referenced in the future.

Stats reference:

Information to store:

  • Events in room (50 most recent, 150 in memory - a later story will have these numbers be configurable)
  • Joined rooms
  • Room state (except m.room.member events of leave or kick, unless they appear in the 50/150 timeline cache)
  • Batch tokens for each room (for backfilling)
  • Account data (including per-room)
  • Read receipts in rooms (typing notifications are stored in memory only)

Estimated storage use (for a 1000 room account):

  • Timeline space (non-state, ~300 bytes/event): ~15mb (~15k/room)
  • Room state space (~5k events/room, ~200 bytes/event): ~1gb (~1mb/room) (it'd be really nice to trim this down)
  • Account data space (including room account data): ~450 bytes
  • Read receipts space: TBD

Evelium should use indexeddb to store this information. For further space-saving measures, we could filter out events which cannot be processed by the client before they leave the sync processing. This could cause problems down the road though if Evelium, for example, gains support for net.arasphere.temperature then historical events will be missing.

@turt2live turt2live added enhancement New feature or request p1 Should be dealt with before p2 labels Mar 5, 2018
@turt2live turt2live added this to the 0.1.0 milestone Mar 5, 2018
@turt2live turt2live self-assigned this Mar 5, 2018
@turt2live
Copy link
Owner Author

Future code will also need to store things like groups data, crypto, etc. At that point it should be possible to do a one-time sync with a filter to get the misc bits of pre-state we need to continue.

turt2live added a commit that referenced this issue Mar 6, 2018
turt2live added a commit that referenced this issue Mar 6, 2018
@turt2live
Copy link
Owner Author

Matthew's initial work at making syncs more manageable might help make storing some of this easier. The initial implementation of storing stuff in Evelium is intentionally limited in scope pending some progress on the /sync front, although it should still be okay for daily use.

turt2live added a commit that referenced this issue Mar 8, 2018
turt2live added a commit that referenced this issue Mar 8, 2018
@turt2live turt2live added p3 Should be dealt with before p4 and removed p1 Should be dealt with before p2 labels Mar 8, 2018
@turt2live
Copy link
Owner Author

Priority lowered pending work on the doc mentioned in my last comment.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request p3 Should be dealt with before p4
Projects
None yet
Development

No branches or pull requests

1 participant