Michael,
Yes, what you suggest is entirely possible. Entire APIs have been
written in C using function pointers and some handy-dandy macros to hide
some of the obfuscation, allowing you to "drop in" different
implementations depending on the need. In C++ it's more transparent
because you can simply instantiate the right type of class to handle
things, but this can be fairly cleanly replicated in C.
In this case, the table resolver would ask for a particular table and
then not especially care how the data was retrieved: local file, HTTP,
poking into a ZIP archive, reading from a static block of memory
somewhere (lest someone have the idea to hard-code an entire table), or
what have you.
Since this would actually be helpful to me for my own purposes (the
default table resolver is too inflexible for my use), perhaps I can take
a look at it and see what can be done... unless there is some objection
to even contemplating this from anyone?
- Anthony
On 2015-09-23 11:04 AM, Michael Whapples wrote:
Hello,
As we are on the topic of reading tables from locations other than the local filesystem, it seems a relevant time for me to ask a question as there may be cases where I would want to access tables from a location not in the local filesystem.
If I understand table resolvers correctly, these are a way that one can implement a custom way of locating tables not stored in the local filesystem. However I get the feeling that what the table resolver does is move the table into a local filesystem location and returns that.
So in my case I am thinking whether it is possible to load a table from a zip or Jar file. I could use a table resolver to extract the table to a temp directory and return the absolute path of the temp file. Is that correct?
I know this doesn't really solve the question of how to read from memory, unless you go down the route of ram disks (if that would even be possible).
I would have thought it might be good if there were a way to provide a custom table reader. I guess I am thinking along that line as a Java programmer where the resolver could return an InputStream object which could be read. I don't know how this could be done in C, but if my memory of some C code is correct it probably would more likely be a function which should be repeatedly called until it reports it could not read any more bytes (a bit like the C functions for copying strings).
This would remove the need of extracting tables to a temp location when wanting to use a table in a zip or Jar file. It probably would also help in the case of reading a table from memory.
Michael Whapples
