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
On 23/09/2015 14:15, John J. Boyer wrote:
If I were still doing programming I would look at
compileTranslationTable.c for references to file operations like fopen,
fgetc and fclose. The module could then be enhanced with functions that
have the same parameters and return values but access memory. It might
be a good idea to give them names like mopen, mgetc and mclose. The file
references in the code could be changed accordingly. mopen would locate
the table in memory and return a pointer. mgetc would simply get the
next character in memory and return it. mclose might do nothing. These
functions and changes might be compiled conditionally, according to the
value of a #deefine
John
