linuxposting/MEOW-Spec
5
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Client message sync #1

New issue
Open
opened 2025-11-19 16:37:04 +00:00 by veneficium · 8 comments
veneficium commented 2025-11-19 16:37:04 +00:00
Copy link

Clients should be kept up to date with the messages file.
If a client is online when the message file is updated the solution is trivial, just send the diff to the client, if a client is not online at the time of update we have to wait for the client to be online to send those updates.

How should we handle offline clients? Should we queue the updates in a file for each user's client? This seems like the most reasonable solution to me but i doubt that it's the most efficient.

Clients should be kept up to date with the messages file. If a client is online when the message file is updated the solution is trivial, just send the diff to the client, if a client is not online at the time of update we have to wait for the client to be online to send those updates. How should we handle offline clients? Should we queue the updates in a file for each user's client? This seems like the most reasonable solution to me but i doubt that it's the most efficient.
veneficium commented 2025-11-19 16:38:03 +00:00
Author
Copy link

The solution needs to account for users having multiple clients that may go out of sync with each other ofc.

The solution needs to account for users having multiple clients that may go out of sync with each other ofc.
ceres-sees-all commented 2025-11-19 16:59:08 +00:00
Owner
Copy link

As the files on the server are the 'master' and should be correct and up to date at all times, would it not be easiest to have the client send an initial sync request when it first launches? It could send the request with the time-stamp of the most recent message and the server could return all messages marked after that stamp

As the files on the server are the 'master' and should be correct and up to date at all times, would it not be easiest to have the client send an initial sync request when it first launches? It could send the request with the time-stamp of the most recent message and the server could return all messages marked after that stamp
veneficium commented 2025-11-19 17:03:21 +00:00
Author
Copy link

How would we handle deleted messages? If we simply remove the message from the file completely the server will have no knowledge of that message ever existing so it will not be able to tell the client to delete it too (and this might mess up file diffs too)

How would we handle deleted messages? If we simply remove the message from the file completely the server will have no knowledge of that message ever existing so it will not be able to tell the client to delete it too (and this might mess up file diffs too)
ceres-sees-all commented 2025-11-19 17:06:37 +00:00
Owner
Copy link

We could just have the client fully re-fetch all files on each launch? they will simply be text so wont be too large, and it will only happen one time per client launch, so not the end of the world if it takes a little longer than a standard message to send

We could just have the client fully re-fetch all files on each launch? they will simply be text so wont be too large, and it will only happen one time per client launch, so not the end of the world if it takes a little longer than a standard message to send
veneficium commented 2025-11-19 17:10:15 +00:00
Author
Copy link

It feels a bit yuck-y but ig it is a solution.

It feels a bit yuck-y but ig it is a solution.
veneficium commented 2025-11-19 17:11:43 +00:00
Author
Copy link

The spec should be updated to include this, i cant do it rn, if u cant either i can do it in 2 or 3 hours.

The spec should be updated to include this, i cant do it rn, if u cant either i can do it in 2 or 3 hours.
ceres-sees-all commented 2025-11-19 17:18:13 +00:00
Owner
Copy link

The other way it could be done would be for the server to keep an 'event history' with all the patches and their relevant time stamps, and the client could keep track of its last received event and request all subsequent events to prevent refetching the file. This could be additionally configured by an admin to remove patches after a certain amount of time?

The other way it could be done would be for the server to keep an 'event history' with all the patches and their relevant time stamps, and the client could keep track of its last received event and request all subsequent events to prevent refetching the file. This could be additionally configured by an admin to remove patches after a certain amount of time?
mewrrythekibby commented 2025-11-20 20:49:21 +00:00
Owner
Copy link

@ceres-sees-all wrote in #1 (comment):

they will simply be text so wont be too large

Are you sure about that?

@ceres-sees-all wrote in https://git.linuxposting.xyz/linuxposting/MEOW-Spec/issues/1#issuecomment-11: > they will simply be text so wont be too large Are you sure about that?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
clientspecs
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: linuxposting/MEOW-Spec#1
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?