Re: VSCHEDULE - Table for queries or not?

[Doug Royer <Doug.Royer@xxxxxxx>]

> Date: Fri, 23 Jul 1999 17:03:58 -0700
> From: sman@netscape.com (Steve Mansour)
> 
> Doug Royer wrote:
> 
> > >
> > >      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
> 
> 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).

So far we only have booked or scheduled items.  If we invent a new
scheduling METHOD, then the original proposal will not work for the
same reason.

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

-Doug
-------------------------------------------------------------------
Doug.Royer@Sun.COM		http://playground.sun.com/~dougr
Pager:				Doug.Royer@Pager.Eng.Sun.com
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL