Re: [Mailman-Developers] Requirements for a new archiver
On Wed, 29 Oct 2003 16:29:09 +0100 Brad Knowles <brad.knowles@skynet.be> wrote:
At 12:41 AM -0500 2003/10/28, J C Lawrence wrote:
Quite, this is how/why NNTP uses Message-IDs are unique indexing qualifiers.
Problem is that client-assigned message-ids are not guaranteed unique.
Right, and that was the point. If we do nothing to Message IDs we don't change external behaviour. If we use a netnews backing store for the archives and we don't dick with the message IDs we run the risk of some messages never reaching the archives. If we use a netnews backing store and dick with message IDs we can offer various levels of guarantee that messages reach the archives, and of pissing off users because we messed with the Message IDs.
As always, you get to pick.
Everything else could quite feasibly collide, and you'd wind up with multiple non-unique message-ids.
In which case the many people currently using ID-based dupe collapsing (eg default Exchange config) will lose messages, and the archives will lose messages....OR...we offer some level of guarantee (see yesterday's discussion) with the matching trade-offs.
You need a guaranteed unique id to be used as a primary index field.
"Need" is a strong word. Its very deployment and use-case sensitive. There are a large number of cases where I'm content to rest on the assurance that the Message IDs arriving at my lists will always be unique. There are also a large number of cases where I'm not willing to make that assessment, as well as a large number of cases where I'm willing to simply discard anu duplicated Message ID messages at the archiver level. Similarly, there are cases where re-writing the Message IDs in any form is significantly troubling, and cases where its not.
"Need"? No. It is a deployment choice with easily understood ramifications.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
At 11:48 AM -0500 2003/10/29, J C Lawrence wrote:
You need a guaranteed unique id to be used as a primary index field.
"Need" is a strong word. Its very deployment and use-case sensitive.
In the case of a database, it is a hard requirement. A primary index field must be guaranteed unique. There is absolutely no way around this issue.
"Need"? No. It is a deployment choice with easily understood ramifications.
Perhaps for the application, but this is a totally different ballgame when it comes to a database. Google for "primary index field", and hopefully you will understand.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On Oct 29, 2003, at 9:41 AM, Brad Knowles wrote:
In the case of a database, it is a hard requirement. A primary index field must be guaranteed unique. There is absolutely no way around this issue.
which is why it many times makes sense to generate your own. Consider, say, identifying all messages with an MD5 hash of the message.... then use that for all of your link generating and access work.
participants (3)
-
Brad Knowles -
Chuq Von Rospach -
J C Lawrence