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

Generalise sync mechanism #141

Open
1 of 2 tasks
chrizandr opened this issue Mar 8, 2020 · 10 comments
Open
1 of 2 tasks

Generalise sync mechanism #141

chrizandr opened this issue Mar 8, 2020 · 10 comments

Comments

@chrizandr
Copy link
Member

I'm submitting a

  • bug report.
  • feature request.

Current Behaviour:

Right now the agent uses sockets to sync itself with a hydrus server.

Expected Behaviour:

This will not work with a purely REST based Hydra server. We need to make the agent generic to work with non-hydrus based Hydra servers.

Steps to reproduce:

Do you want to work on this issue?

@thrishik7
Copy link

@chrizandr I haven't completely understood what has to been done. Should it be refactored by REST over Sockets?

@sudipt1999
Copy link

sudipt1999 commented Mar 19, 2020

@chrizandr currently the hydrus uses a socket functionality as implemented by @Guttz in his pull request #123, so I thing for making it generic we will require something like a generic Resource URIs instead of sockets so that we can communicate with them and maitain a table like structure to keep the records of sync updates.
Adding few Resource URI's like

  1. api/last_updated
  2. api/updates
    Am I getting it right?`

@sudipt1999
Copy link

@xadahiya @Guttz @Mec-iS ! kindly rectify if I am wrong!

@Mec-iS
Copy link
Contributor

Mec-iS commented Mar 21, 2020

sockets are only used for the synchronisation mechanism. Standard REST uses HTTP requests.

As explained multiple times, there are two separate subsystems in place:

  1. the REST server endpoints: these are Hydra-described endpoints
  2. the sync mechanism: this is a hydrus/agent specific functionality (not in the standard), to allow hydrus to push updates to the agent so to save requests

we want to keep this setup, so any change to this is not required.

@sudipt1999
Copy link

@Mec-iS so as given by @chrizandr

Current Behaviour:
Right now the agent uses sockets to sync itself with a hydrus server.

Expected Behaviour:
This will not work with a purely REST based Hydra server. We need to make the agent generic to work with non-hydrus based Hydra servers.

Doesn't the expected behaviour requires to remove sockets since they won;t work with REST based Hydra Server, so can we include some sort of caching to reduce the request!

@Mec-iS
Copy link
Contributor

Mec-iS commented Mar 21, 2020

No. it implies adding HTTP requests when the server is not hydrus. In the case the server is not hydrus (but any other standard implementation), every time some data is needed in the agent it should issue a request to the server.

@sudipt1999
Copy link

sudipt1999 commented Mar 21, 2020

So, how do you propose to generalize the mechanism! @Mec-iS , I mean a rough idea !

@Mec-iS
Copy link
Contributor

Mec-iS commented Mar 21, 2020

the sync mechanism for a non-hydrus server is simply requesting data via an HTTP request everytime is needed. So we should have code in the agent that finds out if the server is hydrus and switch between two modes:

  • if hydrus: use requests AND receive updates on sockets (already implemented)
  • if not hydrus: use only requests (as any other REST client). In this case the agent won't use its local graph but will always issue a request (as it doesn't receive updates and it cannot guarantee the consistency of the data).

In this last case the behaviour is exactly the one for Heracles.ts

@HTTP-APIs HTTP-APIs deleted a comment from sudipt1999 Mar 21, 2020
@sudipt1999
Copy link

@Mec-iS Thanks a lot! I got it how will we generalize the mechanicms now!

@amalthundiyil
Copy link
Contributor

Has this issue been resolved ?

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

No branches or pull requests

5 participants