hydra-python-agent
hydra-python-agent copied to clipboard
HTTP-APIs
Generalise sync mechanism
I'm submitting a
- [ ] bug report.
- [x] 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?
@chrizandr I haven't completely understood what has to been done. Should it be refactored by REST over Sockets?
@chrizandr currently the hydrus uses a socket functionality as implemented by @Guttz in his pull request https://github.com/HTTP-APIs/hydra-python-agent/pull/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
-
api/last_updated -
api/updatesAm I getting it right?`
sockets are only used for the synchronisation mechanism. Standard REST uses HTTP requests.
As explained multiple times, there are two separate subsystems in place:
- the REST server endpoints: these are Hydra-described endpoints
- 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.
@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!
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.
So, how do you propose to generalize the mechanism! @Mec-iS , I mean a rough idea !
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
@Mec-iS Thanks a lot! I got it how will we generalize the mechanicms now!
