Re: (RECUR-LIMIT) The intent/meaning of EXPAND and its usefullness

Preston Stephenson wrote:

>Just my too bits worth.
>
>In our implementation, we expand out recurrence items on creation (so
>STORES:EXPANDED:TRUE).
>We set RECUR-LIMIT to specify the max we will fan out on creation
>For access of the items after that the other recur
>properties/parameters don't make much sense.
>
I do not follow that last sentence. Are you saying that RECUR-LIMIT does 
not apply
to fetch because you have already expanded them? Or are you saying you
strip out RRULE and EXRULE and perhaps RDATE and EXDATE?
Or are you saying there are no more objects after RECUR-LIMIT?

(FYI 'fan out' has another unrelated meaning.).

>For query, EXPAND doesn't make sense and we ignore it (whether or not
>RECUR-EXPAND is set).
>
Then the CUA will know this and also understand because you have
set STORES-EXPANED to TRUE.

>For query, RECUR-LIMIT doesn't make sense, since we only want it to
>apply to storage.
>Can we abstract the limit to just be a limit (say QUERY-LIMIT) of any
>items returned?
>
If a CUA gets RECUR-LIMIT:L and STORES-EXPANDED:TRUE, then it that
is exactly you situation. The CUA will know that it will get up to 'L' 
instances
of a UID and that any over 'L' are not on that CS.

No need for a separate limit property or parameter  for STORES-EXPANED:TRUE
CS's, the limit can only apply to storage as such a CS does not expand 
the instances
at query time.

>For query, RECUR-EXPAND doesn't make sense, since the items are already
>expanded.
>
Yes, when it does apply is when STORES-EXPANDED:FALSE CS's
set RECUR-LIMIT:L, then you will know that you can just re-query 
starting from
the last date/time fetched and that you will get up to 'L' more.

>There is a little problem on RECUR-LIMIT applying to storage and
>query.
>In the case of 2) below, the absence of  RECUR-LIMIT would mean no
>limit.
>The problem arises if you have to have it be two limits (storage and
>query).
>
For a STORES-EXPANDED:TRUE CS, they will never be able to return more
than RECUR-LIMIT objects for a single UID. So they do not need a separate
fetch limit because you can not put in more objects in a EXPAND:TRUE
CS than what the CS itself stored when the CS expanded the instances.
They will always be the same for such a CS.

For a STORES-EXPANDED:FALSE CS, then they store the raw unexpended
object so no need for a separate store RECUR-LIMIT as it is meaningless.
For such a CS RECUR-LIMIT only applies to expanding of objects at fetch 
time.

One RECUR-LIMIT and STORES-EXPANDED covers it.

>On creation we just expand out the item to the limit we can.
>We have no way of passing back a status saying, we would have created
>more.
>
No need as the CUA which sent the object already knows it is a recurring 
object (it
sent it) and it already had seen your RECUR-LIMIT capability.

>(We've just documented it in the past and our customers know to work
>around the limitations.)
>We have no way of adding to an existing recurrence set.
>
METHOD:ADD ?

Or did you mean once RECUR-LMIIT instances have been stored by your
implementation that your implementation can not ADD more?

Or did you men once RECUR-LMIIT instances have been stored by your
implementation that your implementation can not inform the CUA that
there should have been more? I might suggest that you store a private
object with the original recurrence rules in it, when the end is hit 
silently
expand SOME-PRIVATE-RECUR-LIMIT more, and then return or also include
the results to that? Then you can set RECUR-LIMIT large and
STORES-EXPANDED to TRUE and the CUA will never know that you
are somewhat expanding at run time.

>How would you reflect that functionality in CAP,
>"IF-YOU-CREATE-A-RECURRENCE-ITEM-AND-IT-EXCEEDS-THE-LIMIT" what happens
>flag?
>
The CUA knows it is a recurring object and it has seen your RECUR-LIMT.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email protected]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards