On Tue, 20 Aug 2002, Barry A. Warsaw wrote:
The bit about "member keys" and lce's may be inaccurate. I think in general the assumption is that an lce is the key to the member's information, and I doubt you can use something more opaque. But you could try it and we could fix breakages.
I will try to make that opacity work. A question, though, is what conceptually that key should represent. Does it represent a user, or a user's subscription (which is a one-to-many relationship)?
The tricky part, and the part I'm less confident about, is that you need to coordinate transaction boundaries through MailList.Load() and MailList.Save(). Save() is essentially "commit", but we never Save() if there's nothing to do, or if we don't have the list lock.
Hrm. So you're suggesting that all modifications made through the writable interface be queued up in a transaction that isn't committed until .Save()?
But then this could happen: Q: What is Bob's subscription style to XYZ.? A: normal
Change him to digest mode.
Q: What is Bob's subscription style to XYZ.? A: normal
Basically it seems that the "don't commit until .Save()" and the "all state changes happen immediately" contradict one another...
-Dale