On Tue, Nov 12, 2013 at 5:55 AM, Oswald Buddenhagen <[email protected]> wrote: > On Tue, Nov 12, 2013 at 05:06:08AM -0600, Felipe Contreras wrote: >> On Tue, Nov 12, 2013 at 4:40 AM, Oswald Buddenhagen <[email protected]> wrote: >> > On Mon, Nov 11, 2013 at 07:05:04AM -0600, Felipe Contreras wrote: >> >> Oswald Buddenhagen wrote: >> >> > this is now done in the maxmessages branch. >> >> > the option is called ExpireUnread yes/no >> > >> >> you start from the assumption that people would automatically assume >> >> unread messages are not included in this limit, and I think it would >> >> be the opposite for most people. >> >> >> > well, there are two considerations: >> > - i didn't want to change the default behavior >> > - i wanted to default to the safe (don't miss messages) option. though >> > it can be argued that this default is unsafe as far as the size of the >> > initial fetch goes. so maybe i should just make it error out if >> > MaxMessages is exceeded by more than 50% and no explicit setting is >> > present. >> >> That is orthogonal; the default of ExemptUnread can be 'yes'. >> > huh?
ExceptUnread = yes doesn't change the default behavior.. >> >> I think LimitExcemptUnread is much clearer because a) it explains what the >> >> option affects; limits (which could be MaxAge, MaxMessages, etc.), b) the >> >> word >> >> except makes it clear that the limit rule doesn't apply to this kind of >> >> messages. >> >> >> > you meant "exempt". ;) >> > while "limit" may associate better with the "max*" options, it's not >> > self-explanatory either. so given that one needs to look into the man >> > page anyway and the related options are right next to each other, i >> > don't think it's much of a consideration. >> > also, "LimitExemptUnread" is just awkward. it's bad grammar, and sounds >> > plain awful. >> >> ExemptUnread then. >> > the immediate question is then "from what?". By following the rules of rationality it must be a rule, and what kind of rule could affect unread messages? There's only one AFAIK; MaxMesages. Plus if you don't think that's clear, it could be called LimitUnread. In this case there's no mental jump required; the rule it affects is the MaxMessages limit. > there is also another consideration here: if the choice is not otherwise > mandated, it's better to avoid negative option names to avoid confusing > double negation. I don't know what you mean. >> > while "expire" is moderately inaccurate in case of count-limiting, it >> > associates well with the notion that messages spend some time in the >> > local mailbox and then go poof (for whatever reason). therefore i find >> > it reasonably intuitive. >> >> Well I don't. It's very clear that ExemptUnread applies to some kind >> of rule, and the only one that fits is MaxMessage. >> > it's not said that that rule relates to other options. > also, there may be other options that define/change unrelated rules at a > later point. > it really is ambiguous and wouldn't make much sense to you if you > weren't in that context already. At least it's understandable, ExpireUnread is not understandable at all. Nobody knows what "expire" means, it's not even mentioned in the man page, so it's not a known concept. Besides, once you add the ExcessMessageMode: Keep option, it wouldn't really be "expiring" anything, would it? >> Whereas ExpireUnread doen't imply any rule or anything at all that >> relates it to MaxMessages. >> > the association is very clear once you read the man page, and it doesn't > matter before you read it (see above). and it's short and sounds good. No, it does not sound good. And even after you read the man page it still wouldn't be clear, and wouldn't even represent reality (ExcessMessageMode: Keep). > in that sense i think it is a quite well-chosen name. Of course it is, *in your opinion*, which is not surprising. -- Felipe Contreras ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
