Subject: Re: I MOVE we simplify the query language.

From: "John Stracke" <[email-masked]>
Date: Tue, 26 Mar 2002 13:03:11 -0500

>I am happy with that. My issues are for PDA, Cell, and limited
>memory support:
[...]
>                (2) We need some way to for a CS to say that it can not
>                    handle more than (example) 2 logical operators where

I think I'm missing something.  Why would you run a CS on a handheld?

>         (4) Is a vendor really going to make a CUA GUI that allows the
>             CU to ask for all appointments where 'fred' is an attendee
>             and no one else has accepted? And any other variation
>             of that?

You probably wouldn't be able to compose such queries by hand; but a CUA 
might have hard-coded queries that are that complicated.  For example, the 
above query would be useful for Fred's admin.

>                      Does this need to be a query to the CS, or can
>             we limit the queries to something simple like:
>
>                                SELECT * FROM VEVENT WHERE ATTENDEE = 
'fred'
>
>             then let the CUA sort it out what it wants?

That doesn't scale on the CS, though.  Pushing the query back towards the 
store makes for less bandwidth and less CAP processing.  For 
database-based CSes (the only ones that will scale), you want to run the 
query in the DB itself, to get as little data as possible coming back over 
the wire from the DB.

It also hurts CUA performance, especially for limited-bandwidth cases like 
PDAs and cellphones, where users get charged by the byte.

/========================================================\
|John Stracke                    |Principal Engineer     |
[email-masked]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|Know your limits, then destroy 'em.                     |
\========================================================/

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 Mar 2002 12:51:32 -0700

> above query would be useful for Fred's admin.

Sounds like a great example for a stored query :-)

> That doesn't scale on the CS, though.

I am NOT saying that we don't need a QL-FULL, I am saying we need
a QL-MIN that is an exact and limited subset of QL-FULL so that
small device CSs can be implemented without having to have a full
blown database server behind them.

> Pushing the query back towards the 
> store makes for less bandwidth and less CAP processing.

I would suspect that a CUA won't ask for what it can't handle.
And why would expecting a CS that serves N number of CUA, scale
better than 1 CUA doing the same work?

>  For 

Does your database server support 'USING_PROPERTIES()', if not - no it
can't be at that level. If it can't be mapped 1:1 to your database
query language, then the CS is going to have to do exactly what you
say won't scale.

There are forces on this list that do not want an SQL language.
So we invented things that break every database server language.

> PDAs and cellphones, where users get charged by the byte.

I would suspect that those vendors will be using stored queries
and not 90 page requests with complicated queries.

I am not trying to limit a CS from doing a QL-FULL. I am trying
to enable small devices and small implementations to not have to
buy a full database server in order to do CAP-QL.

---

From: Alan Davies <[email-masked]>
Date: Tue, 26 Mar 2002 16:09:40 -0500

>blown database server behind them.

You seem to be making the assertation that CAP must be simple
enough to implement a Calendar Server (CS) on a "small device"
quite regularly, but I can't find any mention to this in the
CAP Requirements Draft; could you point me to the relevant
section, if it exists?

What are these mythical small device CS's; and will they
proliferate at the same rate that Mail Servers and Web Servers
have not proliferated on small devices?

While simplifying the query language has some advantages, it will
make the implementation of small device _CUA_ more difficult, as
John pointed out, due to increased bandwidth (and we're not just
talking about the odd byte here or there, possibly orders of
magnitude more bandwidth), and complexity pushed into the CUA.

>So we invented things that break every database server language.

What forces on this list do not want an SQL language? I haven't
seen them; I've seen reasoned discussion that have pointed out
flaws in the overly-optimistic that plain SQL to query a non-SQL
schema.

--Alan

---

From: "Graham Gilmore" <[email-masked]>
Date: Tue, 26 Mar 2002 16:34:35 -0500

----- Original Message -----
From: "Doug Royer" <[email-masked]>
To: "CalSched IETF" <[email-masked]>
Sent: Tuesday, March 26, 2002 2:51 PM
Subject: Re: I MOVE we simplify the query language.

> blown database server behind them.

    I can see your point about needing a simple QL for implementing a small
CS, Doug, but we can't afford to ignore the "large" implementation while
allowing for the small.  (I seem to recall reading something about the IETF
goals and large-scale deployments....)
    Right now, CAP-QL provides enough functionality to deliver a reasonably
feature-rich CS in a traditional client-server environment.  IF we cut down
CAP-QL to be suitable for implementing a CS on a small device, then we MUST
have a richer query language defined BEFORE last call, not as some magical
"add-on draft" to be done "later"; without it, CAP will only be a toy, not a
useful IETF [draft | proposed] standard.  I don't agree with the thought
that it will take a long time to come up with a good query language (unless
we're forced to use an SQL-like syntax that doesn't fit with the iCalendar
data model); John Stracke has already proposed one reasonable alternative
query language,
(<http://www.imc.org/ietf-calendar/mail-archive/msg03168.html>, thanks for
posting the link earlier John), and certainly others are possible.

    Maybe we should have 2 versions of CAP-QL: the CAP-QL that the list
(more or less) agreed on in January, and a CAP-QL "Lite" for simple CS
implementations.  As CAP-QL was sort of a "one language fits all" compomise,
this would raise 2 questions:
    1) Is CAP-QL as it stands sufficient for those wanting to implement a
"full" CS, or are there more features that would be *needed* (rather than
"this would be cool")?
    2) What would be the strict minimum needed for a CAP-QL "Lite", for a
"simple" CS?  (Doug?)

    Graham

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 26 Mar 2002 15:38:49 -0600

Just a quick thought about Small Devices.

In our various documents we describe a "typical" Calendar User Agent as
probably also have a Calendar Server engine "inside of it" - in order to
hold and consume iCalendar objects a calendar user agent will have to have
some storage capability and native understanding of the iCalendar object
structure - so in many cases a basic calendar server is a part of a calendar
user agent design.

(if not then the user agent design is perhaps nothing more than a screen
display with no actual "application" - rather it relies entirely on data
from a server application for what to show and where - i.e. something very
different than currently envisioned by CAP.

CAP delivers FROM a Calendar Server iCalendar objects - which must then be
used (and almost certainly stored) by the Calender User Agent.

So I think that the answer to the "mythical small device calendar servers"
is that they will have such a server as a part of Calendar User Agents
written for them. Or at least this is a very likely and probable scenario.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Alan Davies
Sent: Tuesday, March 26, 2002 3:10 PM
To: CalSched IETF
Subject: Re: I MOVE we simplify the query language.

--Alan

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 Mar 2002 15:12:49 -0700

Graham Gilmore wrote:

> allowing for the small.

I never said scrap the full QL. I would argue against scraping FULL-QL.

> this would raise 2 questions:

Yes - that was my thoughts.

> "full" CS, or are there more features that would be *needed* (rather than

I think it would allow CAP-QL to extend if needed and not compromise
small devices.

>     2) What would be the strict minimum needed for a CAP-QL "Lite", for a

Bare bones query including allowing for a LITE-CUA to call stored queries
that perhaps were setup by a FULL-QL CUA, even when the LITE-CUA
can not generate those queries. I know that John disagrees with
stored queries, but I don't see why a LITE-CUA could not be built
that ONLY supported pre-defined queries.

Perhaps the best break point would be that a MIN version could
not support any USING operators. This would limit the queries
and force the CUA to do more data processing. But at the same time
allows small CS's to be implemented. Also - MIN would not allow
any parentheses at all. And a limited number of logical operators (1?).
Then the FULL QL could be what CAP-QL is now for and allow a mega-CS.

Maybe define some pre-defined queries that take an argument as
John has pointed out. Get 'today', get everything that changed
since last sync, all non-booked entries, get all alarms for today, ...

I have already mapped most of CAP-QL into SQL (somewhat tested).
My concern is that we are forcing all CS's to be rather huge
implementations that might take a LONG time to be interoperable.

The reason that SQL-MIN existed was because we gave up trying
to do a mega-query language. However in that debate that resulted
in CAP-QL, we forgot that small devices just can do all of that.

I don't see any reason that I can not have a

---

From: Alan Davies <[email-masked]>
Date: Tue, 26 Mar 2002 17:39:02 -0500

>Then the FULL QL could be what CAP-QL is now for and allow a mega-CS.

You seem to think that the USING operators can be left out to provide
a simplified QL, but you haven't yet provided an answer as to which
of the three unsatisfactory options (a), (b), or (c) would be chosen
in their absence:

     http://www.imc.org/ietf-calendar/mail-archive/msg05613.html

--Alan