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?

I just meant RECUR-EXPAND, RECUR-LIMIT.

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

I know, sorry.

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

There is a little confusion in the text then.
It would be helpful if it explicitly states that if STORES-EXPANDED is
true,
RECUR-EXPAND, RECUR-LIMIT, EXPAND are ignored.
At least is that what you said above?

>>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 your 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 ?

We can't support METHOD:ADD.
They have to create a new recurrence set or delete the old set and
create a new one.

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

It hasn't been a problem as of yet.
We are looking to add support for full recurrence in the future.

>>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

Thanks for your input.
Preston