bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] libpsl design


From: Dagobert Michelsen
Subject: Re: [Bug-wget] libpsl design
Date: Sun, 23 Mar 2014 23:06:30 +0100

Hi Daniel,

Am 22.03.2014 um 22:41 schrieb Daniel Kahn Gillmor <address@hidden>:
> 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.

As a distro-builder I would prefer a solution where the library is pretty stable
and where users can pull updated description files via cron, similar to 
geolitedb
updates. Forcing users to update packages from unstable is not very nice.


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process." - xkcd #896

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]