> > Still, that had nothing to do with the workflow recovers in the
model
you
> > espouse. Can you please show me how a REFRESH magically
solves the case
> > of a missed (or purposely deleted by the CU) entry in the chain?
Perhaps
> > George can chime back in and rephrse what Doug's said so that
its clear.
> > Or if someone else out there can show how everything gets resync'd
> > properly when RECURRENCE-IDs change per SEQUENCE Im all eyes!
Anyone??!!
> >
>
Thanks you Bruce! You put in a lot of examples and did a in-depth analysis
of why delta changes RECURRENCE-IDs is a bad thing and I agree with you
100%.
So far, I also don't see a convincing example for the benefit of delta
changes
RECURRENCE-IDs, nor do I see how delta changes RECURRENCE-ID will work
for
Bruce's samples.
Keeping the RECURRENCE-ID constant is straight-forward and easy to
understand. Not only it guarantees workflow will work, but work efficiently.
And it eliminates the whole mess of delta changes RECURRENCE-ID ambiguity.
So can someone
give us the reason why we shouldn't do it? Or can someone walk through
a
complete RRULE
example like what Bruce has done and demonstrate how delta changes
RECURRENCE-ID can achieve the same goal??
Just to add one more perspective to this, Microsoft Exchange 2000 iTIP/iMIP
works with recurring instances with the model of RECURRENCE-IDs never
change. I believe
this is same for Notes. Bruce, can you confirm? If your product requires
interoperability with them,
delta changes RECURRENCE-ID will have nothing but headaches.