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

library considerations #4

Open
sandyfreelance opened this issue Feb 21, 2024 · 0 comments
Open

library considerations #4

sandyfreelance opened this issue Feb 21, 2024 · 0 comments

Comments

@sandyfreelance
Copy link

Needs to be addressed:

I think that we should also consider splitting the library problem into two parts:

  1. Caching of metadata - Many libraries implement the HTTP RFCs already. A client requests some metadata through a hapi-cache proxy server or library, and the RFCs are followed. So hapi-cache does not necessarily need to support the RFCs because HAPI client libraries could use existing libraries for this functionality. However, it may be convenient to support the RFCs. I think we all need to be familiar with the RFC terminology and use the same terms, as appropriate for part 2. below.

  2. Data requests - When a client requests data from a hapi-cache proxy server or library, the response can be built up based on existing data in the cache. This is a non-trivial problem. I had a CS student implement something like this in the Python HAPI client. See the documentation at https://github.com/hapi-server/client-python/blob/master/hapiclient/hapi.py#L204.

We should also consider the motivation for 2. (and why I proposed the project):

a. Because some HAPI servers are slow, Eelco wants to proxy requests through a hapi-cache proxy server (could be local or remote).
b. I want something like the Python client features in the MATLAB client. If I have someone implement the Python features in MATLAB, the features in two client libraries will eventually diverge. We could have the MATLAB client wrap the Python client, but it may be simpler to have the MATLAB client pull down a jar file that starts a caching proxy server, and then the client routes all requests through the proxy.
c. Somebody has to maintain the Python cache code and add features. I prefer to rip it out and include the (hopefully small) jar file for the proxy server in the package and leverage new features developed by someone else.
d. Jeremy was already implementing many of the features in 2. in Autoplot. This code should be available to a wider audience and independent of Autoplot.

The motivation for the database schema is cache sharing among clients. This is tricky because of locking. It is not critical to publish a schema, but I expect we won't regret it eventually.

Bob

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

No branches or pull requests

1 participant