Opened on 03/08/2016 at 11:30:15 AM
Closed on 03/22/2016 at 04:19:12 PM
Last modified on 01/04/2017 at 05:40:22 PM
#3756 closed change (fixed)
Filterlist rendering in python-abp
Reported by: | kvas | Assignee: | kvas |
---|---|---|---|
Priority: | Unknown | Milestone: | |
Module: | Sitescripts | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Platform: | Unknown / Cross platform | |
Ready: | no | Confidential: | no |
Tester: | Unknown | Verified working: | no |
Review URL(s): |
Description
Filterlist rendering library should combine and post-process filterlists the same way combineSubscriptions.py script from sitescripts does it. In particular the following features need to be supported:
- Including other list from filesystem and via http(s) requests,
- Rendering the timestamp,
- Removing duplicate headers and metadata,
- Inserting the checksum into the rendered list,
- Producing .TPL version of the filterlist by converting the filters and metadata and removing/commenting unsupported content.
The rendering code should conserve memory and do all the processing in a streaming fashion as much as possible (the checksum feature makes it impossible to be completely stream-oriented, but we should avoid keeping the whole list in memory).
Attachments (0)
Change History (7)
comment:1 Changed on 03/08/2016 at 11:31:09 AM by kvas
- Blocking 3751 added
comment:2 Changed on 03/14/2016 at 04:22:57 PM by kvas
- Component changed from Unknown to Sitescripts
comment:3 Changed on 03/17/2016 at 12:37:36 PM by kvas
- Sensitive unset
comment:4 Changed on 03/21/2016 at 06:09:36 PM by kzar
- Blocking 3849 added
comment:5 Changed on 03/21/2016 at 06:10:47 PM by kzar
- Blocking 3751 removed
- Priority changed from P3 to Unknown
comment:6 Changed on 03/22/2016 at 04:19:12 PM by kvas
- Blocking 3849 removed
- Resolution set to fixed
- Status changed from new to closed
comment:7 Changed on 01/04/2017 at 05:40:22 PM by abpbot
A commit referencing this issue has landed:
Issue 3756 - Refactor ensure_*state functions
It's not clear if the rendering functionality will be needed anywhere outside of the rendering script (#3849), so the moment we won't expose it as a public API of the library. The issue was folded into 3849 for simplicity.