24 Oct 16 08:44, you wrote to me:
AP>>>> I need to be able to purge the message bases (as they do get quite
AP>>>> large and slow things down) and retain more than 9999 messages.
WV>>> I've changed that to a maximum of 65535, for the next release. ;)
ml>> that's crazy... especially when JAM can have 2M messages and at least
ml>> MSG can store up to 99999999...
WV> Well it's better than the current 9999. And as the config file stores
WV> it as a 16 bits value, that's all I can do without making things
WV> complicated... ;)
it isn't that complicated to increase it to a 32bit or possibly a 64bit
number... then when the new release comes out and setup is run, setup can
easily detect that the config file is from an older version and update it to
the new format... the config file does have a format version number in it for
this type of detection and updating, doesn't it??
AP>>>> I also need to be able to pack the jambases without renumbering
AP>>>> them.
WV>>> Why do you need that?
ml>> some software doesn't take kindly to renumbering the messages
ml>> underneath it... JAMNNTPD comes to mind...
WV> So it stores last read pointers in it's own config? And doesn't use
WV> the .jlr file for that, as it is supposed to?
no... news servers don't know what the last read message is... there's no way
for the client software to tell them... the client software stores the last
read in their own configs on the user's machine... when the BBS renumbers the
message bases, the client has no way of knowing that and no way of knowing what
the new numbers... the only option is to unjoin and rejoin and then mark all
the old messages as read and start again... if this is done daily, users won't
be using that service or they will be complaining long and loud about it being
broken...
ml>> so why pack, you ask? to remove deleted and dead message bodies...
ml>> every time you edit a JAM message, the header is updated to the new
ml>> message body location and the old one is left floating as trash...
ml>> packing the message bases removes the dead wood from deletions and
ml>> edits...
WV> I know that. ;)
ok then... you know why to pack and now you know why to /not/ renumber...
FWIW: i've never knowingly renumbered my system since switching to JAM when we
were beta testing it in RA/FD/FE... it was only recently that it came to light
that FE would do so at a certain point... i think i've taken care of that on
that system but it is still a major problem on others... especially when the
developers mistakenly shove it in automatically... i can understand doing it in
certain circumstances (like when the HMB approaches its limits) but it should
always be an option for the operator to choose... if they break their message
bases because they let the numbers get too large than that's their fault...
even with JAM there is this possibility but the numbers are much larger before
something like this should handled and then it should be handled by notifying
the operator in the logs and letting them make the decision...
)\/(ark
Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... Old BBSers don't die, they just drop their carrier.
---
* Origin: (1:3634/12.73)
|
