Ken Murchison wrote:
Dave Cridland wrote:On Mon Nov 13 21:55:04 2006, Ken Murchison wrote:The value is going to be returned via LISTEXT either way, but I don't see why we need to add a new LISTEXT return option when we already have METADATA, which seems to be a perfect fit.What are LISTEXT return options *for*, then? (Other than to support METADATA).I agree with this in principal, but ...LISTEXT itself is designed to be the basis for "new" LISTable data, I don't see why METADATA should be mandated for everything as well. Otherwise we've really screwed up with going through LISTEXT, and we should have incorporated METADATA directly in LISTEXT.... do we want to create a new return option for every piece of metadata that we come up with?
No, people should use one or the other. However it is perfectly fine if both share the same data store.
Cyrus IMAP uses several vendor-specific mailbox annotations, should we create return options for them?
If they are read-write, then metadata is a much better fit for them.For things that are generated on the fly, it would be better to use LISTEXT. IMHO, LISTEXT would be better for things like sum of messages, and other STATUS-like data.
Things that are generated once on first access and then stored, METADATA is Ok. However this is getting into the grey area between METADATA and LISTEXT. Purely read-only things are also in the grey area.
And remember about difficulty of implementing METADATA on servers. LISTEXT might be already difficult to implement, but unlike METADATA it doesn't require any additional attribute storage facilities from the mailstore.
(I might be repeating myself at this point)
I wouldn't have a stroke if the WG decided to make POSTADDRESS a return option, but I think METADATA is a better fit.