Skip to content
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

Socket management potential solution #296

Open
wants to merge 6 commits into
base: develop
Choose a base branch
from

Conversation

adam-clarey
Copy link
Contributor

This method checks which query/templates an entity should belong to and sends it to the relevant sockets along with the template name so that the client can simply insert it into the the relevant template.

This also includes the entity permissions fix. Instead of setting an entity to 'undefined' if it fails the core permissions (eg, can view own, can view any) it sets entity.validated to true or false. This means that subsequent hook_view can alter this value depending on their own criteria

@FilipNest
Copy link
Contributor

Awesome. I'll have a look and see if we can merge the solutions we came up with somehow. We're doing things a bit differently so I'll link to mine later on. Also thought of a potential enhancement that could open things up beyond just socket feeds.

@FilipNest
Copy link
Contributor

Here's my attempt at a solution: https://github.com/FilipNest/Iris/tree/server-side-liveupdate-controller . I'm still not sure it's right but it seems to be the right direction. The solution in this current pull request, if it works, could be a step between.

The one in my branch uses the core entity fetch system to check queries in order not to duplicate any logic. This way if we ever change the query system we don't have to change it in two places. There are two current problems with it I can see:

  1. It makes an additional database query to check the feeds. I'm sure this can be sidestepped somehow by being clever and creating an in memory database (possibly using NeDB) that mocks the entity fetch but doesn't have to do a full database query. Currently it's a minor drag to performance.
  2. I haven't figured out how to make the entity delete notification only send to people who should receive it. I'm currently just sending it to everyone. I could bypass this with a similar fake database as above but using the live database to check queries that match doesn't work as the entity is no longer there.

Sorting and limiting happens on the client side still but I think that's the same with your method.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants