On Apr 8, 2012, at 9:18 PM, Stephen J. Turnbull wrote: > I don't really see the point of not storing all the IDs, anyway.
Not only does this require excessive resources, but it requires significant infrastructure for failure recovery. (Think backups, journaling, etc.) That requirement may not be an issue for Google, but it is a significant additional burden for small operations, migrations, etc. I support the concept of Stable URI. The concept of using a hash into a large namespace is probably adequate. However, at a minimum, the URI SHOULD include an easily identifiable schema-revision indicator. That way, if the present scheme is found lacking, we can, compatibly, switch to a new schema and a new namespace. Further, by intentionally changing the namespace, based on time, it becomes reasonable to assure uniqueness in all but exceptional situations without requiring infinite perfect memory. Further, by switching namespaces, past faults in that memory become self-healing. I think that migrations, alone, justify the use of a scheme that does not require infinite preservation of all past message IDs. I would hope that the historical experience in the crypto world would convince you of the need to make provision for an unknown future. There, schemes that were thought to be "unbreakable" have been adopted and widely used. Only, well after that time, was it discovered that there was a flaw and a new scheme needed to be utilized. The use of long-lived stable URIs needs to be prepared for that eventuality. Therefore, the URI must self-identify its namespace and the namespace must not be based solely on something that can outlive the use of the namespace. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
