On 03/22/2014 04:00 PM, Tim Rühsen wrote: > I just added the creation of a second library (libpsl-inline) with a slightly > different approach. A tool (psl2c) genrates C data structures from the PSL > ASCII file. This file will be included by psl-inline.c to build libpsl- > inline.so.
This sounds great, Tim.
Would it be possible to make these the same library, with the generated
libpsl-inline object just being a static, pre-generated psl_ctx_t ?
then the library would export an additional variable:
const psl_ctx_t* psl_builtin_ctx;
Or, if you prefer to avoid exporting a variable from a shared object for
whatever reason, a function:
const psl_ctx_t* psl_get_builtin_ctx();
The user of libpsl could either use the builtin one, or initialize their
own, passing the const psl_ctx_t* of their choice to the same function
calls. This would simplify code and linking, i think.
> Also, is creating the library with every change to affected_tld_names.dat
> reasonable ? How often does it change ?
I think mozilla updates the PSL monthly at this point. updating the C
library on the same timeframe doesn't sound too horrible to me. it's
also possible to avoid shipping effective_tld_names.dat at all within
libpsl, and expect the user to supply their own copy when linking.
Within debian, this would just mean libpsl would:
Build-Depend: publicsuffix
I suppose it's possible that a user would want to know information about
the builtin psl file. maybe it'd also be worth exporting a const time_t
psl_builtin_timestamp or a const char* psl_version_info for users who
want some kind of diagnostics about their builtin PSL.
> I would still like to move the discussion to libpsl-bugs, but so far nobody
> is
> reading it ...
I've tried to subscribe, but apparently i have to be approved first.
please approve me! :)
--dkg
signature.asc
Description: OpenPGP digital signature
