Subject: [calsify] VAVAILABILITY - multiple overriding mechanisms

From: Evert Pot <[email-masked]>
Date: Thu, 16 Jul 2015 21:20:12 -0400

Hey guys, I hope I follow proper etiquette by opening several threads
with different subjects as opposed to cramming them all in one.

I have a bit of a design concern/question.

VAVAILABILITY at its core allows us to specify when we are usually busy
using recurrences.

To specify exceptions to regular rules (e.g.: normally I'm available 9-5
but certain weeks I might be on vacation) we can use PRIORITY and a a
new VAVAILABILITY component to specify this.

I just noticed however that there's a secondary way to do overrides:
using additional AVAILABLE components with RECURRENCE-ID and/or EXDATE.

This makes it all a bit harder to implement. My question pretty much
comes down to: is overriding of AVAILABLE instances really needed? Yes,
it increases the flexibility of complex rules, but is this flexibility
really needed. Are there legit use-cases? Could those use-cases still be
fulfilled by removing this feature?

At the moment I'm going to not implement this. I worry that I just
introduce a path in my code that will never be executed, but it also
depends a bit on your response.

Cheers,
Evert

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 17 Jul 2015 10:28:30 -0400

Hi Evert,

> with different subjects as opposed to cramming them all in one.

Multiple threads is fine - makes it a little easier to track specific 
issues.

>From my perspective I don't see it as being more complex - if you already 
have a recurrence processing "engine" to handle VEVENTs, then dealing with 
overrides and EXDATEs in AVAILABLE is not that hard. You are right that 
this does lead to redundancy in that there are two ways to "override", but 
I think overrides using PRIORITY are meant to be applied to large blocks of 
time where the overall pattern of available time needs to be changed, as 
opposed to AVAILABLE overrides where small adjustments to a single 
"schedule" are needed.

I do think being able to override AVAILABLE components is useful - most 
particularly being able to add EXDATEs as that is the most efficient way to 
remove available slots on, for example, a holiday.

I'd like to get Mike's take on this too (he is out on vacation this week).

-- 
Cyrus Daboo

---

From: Evert Pot <[email-masked]>
Date: Fri, 17 Jul 2015 16:09:17 -0400

> have a recurrence processing "engine" to handle VEVENTs, then dealing
> with overrides and EXDATEs in AVAILABLE is not that hard. You are right
> that this does lead to redundancy in that there are two ways to
> "override", but I think overrides using PRIORITY are meant to be applied
> to large blocks of time where the overall pattern of available time
> needs to be changed, as opposed to AVAILABLE overrides where small
> adjustments to a single "schedule" are needed.
> 
> particularly being able to add EXDATEs as that is the most efficient way
> to remove available slots on, for example, a holiday.
> 

The issue I see has a bit to do with user interfaces as well. I worry
that we'll never actually see viable user interfaces that can take full
advantage of this built-in flexibility.

Just based on the examples I've seen, I believe it's more likely that
clients will pick a smaller subset, as for example the apple clients
have done.

I think scope reduction is always a great thing if we can get away with
it ;) Even if you have code lined up to make this easy to do.

This topic leads me to the next question as well:

Given that the clients that exist today *already* are likely going to
support a limited subset, can we give any recommendations in the spec
describing what a client should do with VAVAILABILITY components that
are too complex to express in the UI?

Is the client expected to wipe out the existing data when making
changes, or should it attempt to preserve any existing data and just
write VAVAILABILITY components. If it's the latter, we should probably
try to describe the strategy for this doing this, including reordering
existing PRIORITY's.

Let me know if this makes sense.

Evert

---

From: Michael Douglass <[email-masked]>
Date: Sat, 18 Jul 2015 01:23:12 -0300

There's a significant difference - and this was important for some usages.

Overrides are a requirement for laying out time which might not follow a 
completely rule based pattern.

That is exactly the same approach as for events and tasks.

The use case for availability is that somebody would describe their 
regular availabiity with a single base vavailability component including 
any necessary overrides.

For exceptional periods - such as vacations conferences etc - providing 
a new VAVAILABILITY with higher priority allows one to overrride a 
period of time without modifying the original component.

This is also of use in the smartgrid work - in fact it was that group 
that first asked about the algebra of availability

The first part as Cyrus said is already implemented - it's how we handle 
events and tasks.

The second part - using priority - is important to a number of use cases

Availability is a little different from events. People lay out their 
availability - 9-12 on weds, 15:00-17:00 on thurs etc - and want to be 
able to leave it untouched.

On 7/17/15 11:28, Cyrus Daboo wrote:
> with overrides and EXDATEs in AVAILABLE is not that hard. You are 
> right that this does lead to redundancy in that there are two ways to 
> "override", but I think overrides using PRIORITY are meant to be 
> applied to large blocks of time where the overall pattern of available 
> time needs to be changed, as opposed to AVAILABLE overrides where 
> small adjustments to a single "schedule" are needed.
>
> I do think being able to override AVAILABLE components is useful - 
> most particularly being able to add EXDATEs as that is the most 
> efficient way to remove available slots on, for example, a holiday.
>

---

From: Michael Douglass <[email-masked]>
Date: Sat, 18 Jul 2015 01:30:28 -0300

> it ;) Even if you have code lined up to make this easy to do.

This was a feature that was requested. I don't know that we go about 
adding complexity without some reason.

We hadn't considered this issue until we were asked to. I've had a 
number of questions from tha OASIS group on this issue which leads me to 
believe they are actively implementing it.
> try to describe the strategy for this doing this, including reordering

I believe the priority approach makes it easier to handle and represent.

However, apparently we already have the situation where clients don't 
support RDATE which  would have thought was the easier part. Not sure 
what to say about that.

I'll be out of touch again periodically - back in the US but travelling 
around Maine
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify