Server should indicate if a vacation is active

[Benoit Tellier]

Nowadays, the JMAP server returns a VacationResponse.

This vacation response comport :
 - an enable field
 - a fromDate
 - a toDate

To know if the vacation is active (ie : response wil be sent to incoming mails) the client needs to verify the date is in the range and the vacation is enabled.

This approch is limited as the client might have some issue with its local time (and thus might make errors on the activate status). Moreover, we concider this operation should belong to the server.

Thus, we propose to add an additional field to the VacationResponse : "isActivated"

Optional, calculated on the server side, ignored on client's SetVacationResponse request, it is true if the vacation is activated, false otherwise.

See https://github.com/jmapio/jmap/pull/50 for actual spec modifications.

Regards,

Benoit

[Bron Gondwana]

I'm generally adverse to sending calculated values like this through the API.

 

I would be happy with an API call to get the server's current time value which could then be used to calculate whether the vacation was active via simple strcmp if you want, since ISO8601 dates are lexically sortable.

 

Otherwise the client is displaying a value which may go stale within a second of being calculated, causing the display to be incorrect, and the client need to know if it should be checking for an updated value.

 

Bron.

--

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 jmap-discuss...@googlegroups.com.

To post to this group, send email to jmap-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jmap-discuss/13bee244-a7a7-43cf-8d0e-65d5227083e6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

  Bron Gondwana

  br...@fastmail.fm

 

 

[Neil Jenkins]

On Fri, 24 Jun 2016, at 08:44 PM, Bron Gondwana wrote:

I'm generally adverse to sending calculated values like this through the API.

 

Yes, I agree. This doesn't fit with the JMAP model, which as far as possible tries to avoid sending calculated values due to the difficulty in keeping them in sync.

 

I would be happy with an API call to get the server's current time value

 

I think this is a better approach if this functionality is necessary (I'm not entirely convinced it is, given that most devices these days sync their clocks via the internet, so it's rare to be skewed more than a second out).

 

Neil.

[D David]

Hey guys,

So you really think we should recode the time-checking logic on all clients? Isn't that simpler to implement only at the server-level?

Regards,

David

[Benoit Tellier]

I back up David's thoughts.

Moreover, Isn't keeping time up to date across sever and client also difficult in a distributed system, as it may also become out of sync ? Isn't it just moving the problem ?

Regards,
Benoit

[Bron Gondwana]

if (serverinfo.now >= vacation.start && serverinfo.now <= vacation.end) {

  vacationIsActive = true;

}

 

In perl I would use 'ge' and 'le', and of course in C I'd use strcmp - but I believe javascript uses the same operator for string comparison.

 

Keeping time and date accurate to within microseconds across a distributed system is hard.  Keeping it accurate to within a minute is not difficult at all.

If this information has to be more accurate than a minute, you're deluding yourself that it will be accurate on the client when it's displayed.

 

The only time this would make sense is if the server actually made an internal changed based on the start and end of the vacation time, by setting an internal flag, and hence changing a modseq (aka: generating a new state token for the vacation/filter rules data type).

 

But if the model is that the server stores vacation information as a message and a date range in which that message is accurate, then the protocol should say those facts - not computed values at a point in time.

--

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 jmap-discuss...@googlegroups.com.

To post to this group, send email to jmap-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jmap-discuss/83408ce5-cf57-45ee-a2b1-9527acc918c3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

  Bron Gondwana

  br...@fastmail.fm

 

 

[Neil Jenkins]

On Monday, June 27, 2016 at 3:22:28 PM UTC+7, D David wrote:

So you really think we should recode the time-checking logic on all clients? Isn't that simpler to implement only at the server-level?

 

Not really. Here's the entire code in our system for determining if the vacation is active:

 

var vacationIsActive = function ( vacation ) {

    var now = Date.now();

    var fromDate = vacation.fromDate;

    var toDate = vacation.toDate;

    return vacation.isEnabled &&

        ( !fromDate || fromDate <= now ) &&

        ( !toDate || toDate > now );

}

 

On Mon, 27 Jun 2016, at 06:26 PM, Benoit Tellier wrote:

Moreover, Isn't keeping time up to date across sever and client also difficult in a distributed system, as it may also become out of sync ? Isn't it just moving the problem ?

 

Huh? You don't have to do anything. The OS is in charge of making sure its time is correct, and they do a pretty good job of that these day; all modern systems synchronise their time via NTP or similar. If you're really concerned you could add an API to request the "server" time and then cache the difference if the local time is skewed, but honestly we use this system in production and I've never seen a support ticket from anyone running into a problem due to out-of-sync local time.

 

Neil.

[D David]

Sorry I posted too fast, I actually don't support the new isActivated property :( There was a misunderstanding between Benoit and me.

My original proposal was to allow isEnabled to be computed by the backend, so that a client could rely on the server to know whether the vacation response will actually be sending messages or not. It's an implementation detail that should at least be written as such in the spec...

What do you think?

[Neil Jenkins]

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.

[Benoit Tellier]

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
}

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.

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...

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

[Bron Gondwana]

On Mon, Jun 27, 2016 at 7:23 PM, Benoit Tellier <benoitt...@gmail.com> 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 jmap-discuss...@googlegroups.com.
To post to this group, send email to jmap-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jmap-discuss/302e77c1-9fb1-4152-96cb-1a1c0e09e0d5%40googlegroups.com.

[Benoit Tellier]

Ok, I fully understand your post.

So we agree isEnabled should be immutable and not computed.

This is not what David proposed. To take his own words :

> My original proposal was to allow isEnabled to be computed by the backend

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.

Regards,

Benoit

[Bron Gondwana]

On Mon, Jun 27, 2016 at 7:34 PM, Benoit Tellier <benoitt...@gmail.com> 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jmap-discuss/3a907799-0d85-4022-8703-c335ef2a136c%40googlegroups.com.

[Bron Gondwana]

Anyway - I think we've been talking past each other a fair bit here, and it's late and I'm tired and argumentative!

isEnabled is clearly good, so that you can turn your vacation message on and off.

Some people just use the same message and set start: null, end: null and turn it on and off as required.

Others might want to add a new vacation object every time they are on leave, and never disable it - just use the date range to control when it happens.

Finally, some might just update the dates on their single vacation object to the next time they are going on vacation each time they plan a vacation.  Obviously for those people, the past state of the their vacation object will be forgotten after they change it.  Regardless of whether we have an "isActive" computed by the server.

Bron.

To view this discussion on the web visit https://groups.google.com/d/msgid/jmap-discuss/3a907799-0d85-4022-8703-c335ef2a136c%40googlegroups.com.

[Matthieu Baechler]

Hi there,

Le lundi 27 juin 2016 03:22:51 UTC+2, Neil Jenkins a écrit :

On Fri, 24 Jun 2016, at 08:44 PM, Bron Gondwana wrote:

I'm generally adverse to sending calculated values like this through the API.

 

Yes, I agree. This doesn't fit with the JMAP model, which as far as possible tries to avoid sending calculated values due to the difficulty in keeping them in sync.

 

Ok, so at the same time we proposed to compute a generated plain text field for email content.

I mean, it looks like the rational here is more : we think it's cheap to code it in every clients. But what if the criteria for computing vacation activation becomes more complex with time ?

I would make instantly all client wrong about their computation, doesn't it ?

-- 

Matthieu Baechler 

[Bron Gondwana]

The computed text is not time dependent. The "is vacation active right at this moment" flag is time dependent. It gets stale.

--

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 jmap-discuss...@googlegroups.com.
To post to this group, send email to jmap-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jmap-discuss/33505393-192e-4627-94ee-6acd121bdf5a%40googlegroups.com.

[Matthieu Baechler]

On Fri, Jul 8, 2016 at 9:37 AM, Bron Gondwana <brongo...@gmail.com> wrote:

The computed text is not time dependent. The "is vacation active right at this moment" flag is time dependent. It gets stale.

Ok, good point.

Nonetheless, my others are still valid I guess.

-- 

Matthieu Baechler