With the Live Caller ID example server, the caller lookup dataset is defined in an input.txtpd and processed by running a ConstructDatabase command which creates a block.binpb and an identity.binpb file. In other words, a static input file is being processed into static block and identity files.
However, in the real world, the data content for identified and blocked numbers is something which is in a constant state of flux and evolution, as new numbers becoming available, old ones become stale, numbers which were initially considered safe change into being considered malicious etc. etc. Is the example server just that, merely an example using fixed datasets, and an actual production server is able to use live every changing data to formulate its response back to the iPhone OS query?
Here's a concrete use case - suppose it's a requirement to permit US nanp numbers but to block anything else. The total number of non US nanp numbers is so large and ever changing that it would be unfeasible to attempt to capture them in an input.txtpd file and then process that, and then to re-capture and re-process it endlessly. Instead what would be required is the ability for the Live Caller ID server to evaluate at query time, using a regular expressions for example, if a number is nanp or not. Is this possible?
Is the example server just that, merely an example using fixed datasets,
Yes, that's exactly what it is. The example server is using a trivial implementation to demonstrate the basic architecture and design. It's internal implementation is definitely not how real world implementations are expected to function.
and an actual production server is able to use live every changing data to formulate its response back to the iPhone OS query?
Yes, that's exactly how I'd expect a real implementation to function. Frankly, the architecture we've built only really makes sense because the data CAN'T be captured in a start forward fixed data set, even a very larger one.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
