View Revisions: Issue #5282

Summary 0005282: Gottem's todo list yo
Revision 2019-07-13 19:08 by Gottem
Description Just a "collection issue" to keep track of shit I have to do for U5. =]
Revision 2019-05-31 22:44 by Gottem
Description Just a "collection issue" to keep track of short-term shit I have to do for U5. =] Perhaps if it gets too big I'll split it among different issues but it should be fine for now. :D

1.0, DONE) m_storetkl:
<Syzop> I see you write them in binary and then have to resolve them when reading back to characters or strings.. so I would do that the other way around.. writing them that way :)
<Syzop> and then (different situation): we have some timestamps, tkl->expire_at, tkl->set_at, tkl->ptr.spamf->tkl_duration, we could write some general 64 bit writing/reading int function for that I think

1.1, DONE) subtype is currently written and read but not passed along to anywhere. :D It might be necessary for softbans or it might simply be duplicate information. spamfilter_target_inttostring(tk->subtype) resolves to a target string but I'm using tk->usermask which holds the exact same information most likely.

1.2, DONE) Speaking of softbans, make sure that shit works/keeps working after re-adding em.

1.3, DONE) Instead of writing on every TKL_ADD/DEL, use an EVENT to do it every X minutes (configurable?) and prolly on MOD_UNLOAD too.

1.4, DONE) Write to a tempfile first and if all good then move it to the "real" path.

1.5, DONE) Skip tklines with flag 'f' (built-in spamfilters or added through a .conf) on write too.

1.6, DONE) Fix memory leak when readDB() returns -1 mid-way.

1.7, DONE) For Z:Lines it should prolly use the new hash thingy instead of indices. =]

1.8, DONE) Rename m_storetkl to tkldb.

2) Port m_tklexcept, but keep in mind some of the changes done for m_storetkl (like convert_to_absolute_path() instead of snprintf'ing PERMDATADIR etc).
Revision 2019-05-30 20:09 by Gottem
Description Just a "collection issue" to keep track of short-term shit I have to do for U5. =] Perhaps if it gets too big I'll split it among different issues but it should be fine for now. :D

1.0, DONE) m_storetkl:
<Syzop> I see you write them in binary and then have to resolve them when reading back to characters or strings.. so I would do that the other way around.. writing them that way :)
<Syzop> and then (different situation): we have some timestamps, tkl->expire_at, tkl->set_at, tkl->ptr.spamf->tkl_duration, we could write some general 64 bit writing/reading int function for that I think

1.1, DONE) subtype is currently written and read but not passed along to anywhere. :D It might be necessary for softbans or it might simply be duplicate information. spamfilter_target_inttostring(tk->subtype) resolves to a target string but I'm using tk->usermask which holds the exact same information most likely.

1.2, DONE) Speaking of softbans, make sure that shit works/keeps working after re-adding em.

1.3, DONE) Instead of writing on every TKL_ADD/DEL, use an EVENT to do it every X minutes (configurable?) and prolly on MOD_UNLOAD too.

1.4, DONE) Write to a tempfile first and if all good then move it to the "real" path.

1.5, DONE) Skip tklines with flag 'f' (built-in spamfilters or added through a .conf) on write too.

1.6, DONE) Fix memory leak when readDB() returns -1 mid-way.

1.7) For Z:Lines it should prolly use the new hash thingy instead of indices. =]


2) Port m_tklexcept, but keep in mind some of the changes done for m_storetkl (like convert_to_absolute_path() instead of snprintf'ing PERMDATADIR etc).
Revision 2019-05-17 18:47 by Gottem
Description Just a "collection issue" to keep track of short-term shit I have to do for U5. =] Perhaps if it gets too big I'll split it among different issues but it should be fine for now. :D

1) m_storetkl:
<Syzop> I see you write them in binary and then have to resolve them when reading back to characters or strings.. so I would do that the other way around.. writing them that way :)
<Syzop> and then (different situation): we have some timestamps, tkl->expire_at, tkl->set_at, tkl->ptr.spamf->tkl_duration, we could write some general 64 bit writing/reading int function for that I think

1.1) subtype is currently written and read but not passed along to anywhere. :D It might be necessary for softbans or it might simply be duplicate information. spamfilter_target_inttostring(tk->subtype) resolves to a target string but I'm using tk->usermask which holds the exact same information most likely.

1.2) Speaking of softbans, make sure that shit works/keeps working after re-adding em.

1.3) Instead of writing on every TKL_ADD/DEL, use an EVENT to do it every X minutes (configurable?) and prolly on MOD_UNLOAD too.

1.4) Write to a tempfile first and if all good then move it to the "real" path.

2) Port m_tklexcept, but keep in mind some of the changes done for m_storetkl (like convert_to_absolute_path() instead of snprintf'ing PERMDATADIR etc).