Re: Broaching the idea of ANNOTATE-LESS (a.k.a COMMENT)

[Dan Karp <dkarp@xxxxxxxxxx>]

> My comment to Dan on this was that it might make sense to have a way
> to "profile" ANNOTATE so that servers could offer limited portions
> of it. e.g. a server might choose not to implement either SORT'ing or
> SEARCH'ing on annotations and that could be indicated via
> ANNOTATE-NOSORT and ANNOTATE-NOSEARCH capabilities. e.g. if a server
> wanted to support a limited set of entries, then a new
> 'ALLOWEDENTRIES' option to SELECT could be used to return the set of
> supported entries on a mailbox (e.g. just "/comment" in Dan's example)
> - this could also cover support for .priv and .shared.

This would definitely work, but I fear that would just further complicate an extension that's already got complex syntax and complex semantics.  I'm hoping for a stripped-down subset of the functionality with correspondingly stripped-down syntax and semantics -- basically, a simple feature expressed simply.

> The benefit of doing this, rather than inventing a new extension with
> new syntax, is that it offers an upgrade path to full annotate. It
> also means that anyone implementing full annotate on a client will be
> able to easily handle "less capable" servers by simply looking at what
> is supported. I think this is better than having two extension. This
> could be done as a follow-up to the current "experiment".

Going off my own experience (which may not be as generalizable as I'd like), it's not difficult for us to add new syntax as long as it uses the same existing underlying data store.  If we *could* support the full ANNOTATE feature set, the extra overhead to also support COMMENT would be minimal.  Of course, your mileage may vary.