You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think that we should also consider splitting the library problem into two parts:
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.
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
The text was updated successfully, but these errors were encountered:
Needs to be addressed:
I think that we should also consider splitting the library problem into two parts:
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.
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
The text was updated successfully, but these errors were encountered: