Subject: Re: W-23 CAP Calendar property .. overlapped booking

From: Doug Royer <[email-masked]>
Date: Thu, 19 Aug 1999 12:31:17 -0700 (PDT)

> From: [email-masked]
> Date: Wed, 18 Aug 1999 17:32:41 GMT
> 
> Doug:
> Having CONFLICTS as a component property just doesn't scale. If I have to 
> search through all 3200 entries currently on my calendar to figure out if 
> I can book a conflicting event, each time I get either an SCS "REQUEST" or 
> a CCS "CREATE" CAP command we are doomed!

I can certainty make it scale :-)  On other words IF it were a standard
- don't do it that way and you will not have a performance or
salability problem :-)

Example:  In your implementation have a look-aside persistent cache
for each calendar of the VFREEBUSY time.  Make it a 3 state mask;
BUSY, BUSY-NO-DUPS, FREE. If someone schedules time and that
time is not BUSY-NO-DUPS - nothing to look up.

> This should only be a calendar level property for performance and
> salability reasons.

I do not agree that it is a performance or salability issue.

> You are entirely RIGHT! Using transparency and priority doesn't say you 
> can't schedule conflicts. It does say what the CUA should do for UI 
> display (for example) when it retrieves these from the CS. For example a 
> PRIORITY:1 event conflicting with a PRIORITY:2 event might be displayed to 
> show the conflict but different priorities.

> There is also the issues of the practicality of making this a component 
> property. For example, how can I have a DATE event for July 14th, Bastille 
> Day if there is an event for 1-2PM on July 14th for an obligatory meeting 
> with my manager?

I assume that Bastille Day would not be on your calendar as
TRANSP:OPAQUE?  If it were, then you as the CU would have to decide
which you wished to do - that is one of the points for the existence
of this property.

You point seems to argue in favor of it also being a component property.
So you don't have that problem - the CU decides.

Which brings up another point (I think you were saying).  That if the
property exists in a component, then it would only apply to
TRANSP:OPAQUE components.

> Naw, the interactions of this at the event level will add 
> a level of complexity that we just haven't thought out.
> If the calendar allows CONFLICTS:TRUE, then we should allow a CS to define 
> them as such.

I don't agree with your arguments. It's what is needed or not.
If it is needed, there are ways to get it to work in acceptable way.

Also another point that this discussion brings up:

Do all properties get propagated out when extracted (by what ever
means) from the CS?

By this I mean.  IF we had a CONFLICTS property, should it be a user
property and not a over the wire component property.  So perhaps it is
something the user sets/unsets (a CAP only feature), not something
that would go into a PUBLISH, REFRESH, ...  with the component.  In
that way no one could send you an component where conflicts were
disabled.  Only the CU that inserted the component could decide;
directly or by agent?

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Alexander Taler <[email-masked]>
Date: Tue, 24 Aug 1999 12:03:46 -0400

> time is not BUSY-NO-DUPS - nothing to look up.

With a calendar level CONFLICTS property, I have to find all 
overlapping events with TRANSP:OPAQUE before I can book an 
event.

With a component level CONFLICTS property, I have to find all
overlapping events with TRANSP:OPAQUE, and CONFLICTS:FALSE, 
before I can book an event.

(Of course it can be cached like Doug suggests, which would
probably be more efficient.)

They both sound like the same amount of work to me, and having 
CONFLICTS at the component level increases flexibility a _lot_,
so we need it.

And, what I hope is a clarification:

Who polices the CONFLICTS property?  I presume that the CS does.
Does it mean an error code which I receieve in response to a 
CREATE, which indicates that a conflict was found?

[snip]
 
> disabled.  Only the CU that inserted the component could decide;

I think that in some old iTIP discussions (adding an attendee 
to an event) it was agreed that not all information would 
have to be sent to other Attendees.  It would seem to be at 
the discretion of the user and client software.  Perhaps some
guidelines would be useful, since some properties are clearly
not appropriate for transmission.

Alex