Subject: Re: VSCHEDULE - Table for queries or not?

From: Doug Royer <[email-masked]>
Date: Fri, 23 Jul 1999 15:41:40 -0700 (PDT)

> Date: Mon, 19 Jul 1999 18:45:00 -0700
> From: [email-masked] (Steve Mansour)
> X-Accept-Language: en
> To: CalSched working group <[email-masked]>
> Subject: VSCHEDULE - Table for queries or not?
> List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
> List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
> 

> In Oslo, we discussed a VSCHEDULE table. It is described in the CAP
> draft. Conceptually, it can be thought of as the place where
> "scheduling" messages are kept until they handled or booked.
> 
> One issue that came up is whether or not VSCHEDULE should be used as a
> table in a query. That is, to query for components that have been
> scheduled (not booked) there are a couple of approaches. One way would
> look something like this:
> 
>      BEGIN:VQUERY
>      QUERY:SELECT (*);
>      FROM (*);
>      WHERE (METHOD = REQUEST OR  METHOD = PUBLSH OR
>      METHOD = ADD OR  METHOD = CANCEL OR  METHOD = REFRESH OR
>      METHOD = COUNTER OR  METHOD = DECLINECOUNTER);
>     END:VQUERY

Or more simply:

      BEGIN:VQUERY
      QUERY:SELECT (*);
      FROM (*);
      WHERE (METHOD != CREATE);
     END:VQUERY

> A couple of issues with with this query are:
> 
>   1. where are things like REFRESH messages kept? They aren't VEVENTs or
>      VTODOs or VJOURNALs.
     
Why not in the same table?

>  2. it is verbose (not a big deal, but keeping things concise is a good
>     goal)

The only "booked" appointment was "CREATE" (I think).

> Another way to do this might be:
>
>     BEGIN:VQUERY
>     QUERY:SELECT (*);
>      FROM (VSCHEDULE_TABLE);
>     END:VQUERY
>
> If we go this route, it means that VSCHEDULE gets a more formal role in
> our schema. It addresses the issue of where scheduling messages go until
> they are handled. But it was not clear that people wanted this.

It also means that the number of tables double. Don't forget that
a VEVENT is not just one table, its a collection of property and
x-component tables.

> Are there other issues with these approaches?  Which approach do you
> prefer?  Is there yet another way?

One set of tables. Use METHOD != CREATE or METHOD == CREATE.

> -Steve

---

From: [email-masked] (Steve Mansour)
Date: Fri, 23 Jul 1999 17:03:58 -0700

>       WHERE (METHOD != CREATE);

this will work provided there is no other value for METHOD that is not a
scheduling method. Did we ever decide how tombstoned appointments will look.
Wouldn't their method be DELETE ?  Even so,, we would have (METHOD != CREATE
and METHOD != DELETE).

> Why not in the same table?

They certainly could be in the same table. If no one wants to make a case for
VSCHEDULE, we should keep them in the same table.

> a VEVENT is not just one table, its a collection of property and

yep

> One set of tables. Use METHOD != CREATE or METHOD == CREATE.

If anyone thinks that VSCHEDULE should be a table of its own, please speak up.
I thought there were some folks in Oslo that spoke in favor of it. If not,
we'll press on without VSCHEDULE.

-Steve