Cyrus Daboo wrote:
Hi Alexey,
Hi Cyrus,
--On November 13, 2006 8:29:16 PM +0000 Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote:This is more of a generic question, but when should items like this be METADATA as opposed to a LISTEXT item? To me, POSTADDRESS really feels like a property of the mailbox as opposed to a property of the mailstore. I see LISTEXT items as mailstore properties (e.g., one mailbox is a child of another) and METADATA as mailbox properties. So I would prefer to see this as a METADATA item.The main difference is that METADATA data is usually read-write (with exception of /motd), while POSTADDRESS never is. It has to be generated by the server.METADATA is only 'usually read-write' because most of what we have defined up until now has been that way. That's not to say METADATA was never intended for read-only items.
Fair enough. This is one of the generic discussions we need to have before METADATA is published. I generally consider METADATA to be unsuitable for things generated on the fly.
And both are reported with extended LIST anyway. Also, METADATA is more difficult to implement on the server. This is not a problem by itself, but considering my comment above it would require additional justification. One question worth asking is: does the POSTADDRESS have to be searchable? I doubt it is.I don't have any use cases for searching POSTADDRESS but then I don't have any for searching /motd either. Again, I think whether it needs to be searched or not is not relevant to whether it is LISTEXT or METADATA.
Well, if a piece of data has to be searchable, it strongly speaks in favor of METADATA.
Plus its MUCH easier to extend using METADATA than LISTEXT - you just register a new entry - its not a whole new extension, with a new CAPABILITY etc.The server still need to know that a value is not writable by the client. Ideally, the client should recognize the value and don't try to write it.So in practice both require the same amount of work to be implemented on the server.I disagree - I think it will be much easier to add a new metadata 'schema' item than to go delving around inside of LISTEXT parsing code to do the same thing and have it advertise the capability.
I strongly disagree with your disagreement :-). Adding new LIST return options should be easy if one's code is structured right (Selection options are a completely different story). For METADATA, one would still have to add the same code to generate values on the fly.