On Mon, Jun 27, 2016 at 7:34 PM, Benoit Tellier <[email protected]> wrote:
> Ok, I fully understand your post. > > No, you really don't, unless we don't have a common technical language. > So we agree isEnabled should be immutable and not computed. > > isEnabled it mutable. It's a switch. You can change its setting at any point, that's not what immutable means. It's not time-dependent. Once you set it, it stays set - the server doesn't change it. > This is not what David proposed. To take his own words : > > > My original proposal was to allow isEnabled to be computed by the backend > > I would definitely reject that proposal, because: > My previous answer was just about saying if isEnabled is a computed value, > then we will have troubble. If ever we want to return a computed value, we > should do it on an other field to avoid ambiguous scenari. > > _IF_ we wanted to have a computed value, which Neil and I certainly don't - then it can't be called isEnabled, because that name is already in use for a switch - and as you have correctly noted, you wouldn't be able to remember the user's intent when setting the switch if the server changed the value of isEnabled! Bron. On Monday, June 27, 2016 at 4:28:03 PM UTC+7, Bron Gondwana wrote: > > > > On Mon, Jun 27, 2016 at 7:23 PM, Benoit Tellier <[email protected]> > wrote: > >> I am also in favour of clarifying this. >> >> Do we agree that, as a client, I can update from / to dates even if the >> vacation is not enabled ? >> >> As such, I can first disable the vacation by sending an update with : >> >> { >> isEnabled : false, >> fromDate : null, >> toDate : null >> } >> >> > That's not what you would do. You would disable the vacation by sending: > > { > isEnabled: false > } > > Why would you null the dates? That's just silly. > > > >> Then modify the dates : >> >> { >> fromDate: "date in one week", >> toDate : "date in two weeks" >> } >> >> After this I will get this as a result from the GetVacationResponse : >> >> { >> isEnabled: false, >> fromDate: "date in one week", >> toDate : "date in two weeks", >> textBody : "My so desired vacation text" >> } >> >> Now, if I sended this as an update : >> >> { >> isEnabled: true, >> fromDate: "date in one week", >> toDate : "date in two weeks" >> } >> >> I will end up with the exact same result, as we are out of the date >> range, so isEnabled is false. We can no more differenciate a vacation in >> one week from a vacation that will never happen, but happen to have some >> fromDate and toDate specified. >> >> > You are confused between two concepts: > > isEnabled - this is like a light switch that's turned on. If there is > power, the light will come on. The power is only connected between "in one > week" and "in two weeks" from now. If the switch is still on at that > point, the bulb will light. > > isActive - this is a computed value which tells you if, RIGHT NOW, the > light is on - aka, you would receive a vacation response if you emailed > this account. > > Neil and I are in favour of sending isEnabled - the state of the light > switch - over the API. We're not in favour of sending isActive - the > current state of the lightbulb. That's a computed value, not a settable > field. > > >> With such a specification, the client can just know if the vacation is >> active right now. But can not know about not yet active vacations. UX >> scenari like displaying the vacation in a calendar are no more possible... >> >> > Sure it can, because isEnabled doesn't change with the date. It's just > what the light switch is set to. > > > >> That's why I am reluctant to modify the isEnabled value, and propose to >> add an other value (isActivated) that prevents from this ambiguity. >> >> Regards, >> >> Benoit >> >> On Monday, June 27, 2016 at 3:54:48 PM UTC+7, Neil Jenkins wrote: >>> >>> Right, I see where the misunderstanding is; we need to clarify this in >>> the spec. The isEnabled property is *combined* with the from/to dates, >>> which are both optional/nullable (if the vacation response should be >>> enabled until manually turned off), to decide whether to send a vacation >>> response or not. >>> >>> Neil. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "JMAP" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jmap-discuss/302e77c1-9fb1-4152-96cb-1a1c0e09e0d5%40googlegroups.com >> <https://groups.google.com/d/msgid/jmap-discuss/302e77c1-9fb1-4152-96cb-1a1c0e09e0d5%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "JMAP" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jmap-discuss/3a907799-0d85-4022-8703-c335ef2a136c%40googlegroups.com > <https://groups.google.com/d/msgid/jmap-discuss/3a907799-0d85-4022-8703-c335ef2a136c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "JMAP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jmap-discuss/CAKUUC6XvK_ruKmdqkKgn7VaCbRwdVe%3DxceLyW9or4D92mR9DCQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
