.NET api returns different data than web-interface upon querying a calendar

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use the normal google calendar web interface to confirm a recurring
event which another user has invited you too.  Delete a number of specific
instances of that recurring event.
2. Use the Google Calendar Demo Application (.NET) to browse your calendar
for those days which used to have a recurring event authored by someone
else, but on which you've deleted that specific instance
3. Observe that the .NET api-based application still displays those events
(sometimes!), but that the web-interface does not.

What is the expected output? What do you see instead?
The API should return the same data as the web interface.  It does not.

What version of the product are you using? On what operating system?
I'm using 1.1.1.0, tested on .NET 2.0 and on .NET 3.5 (beta), both on
windows XP.  (They perform identically).

Please provide any additional information below.
I've not been able to exactly determine when the API returns different data
than the calendar, however, it's not a simple caching issue (even events
deleted weeks ago still appear in the API version, and I suspect that
events which _do_ appear in the web-interface sometimes don't appear in the
 API version, though I can't say for sure, since I haven't been able to
reproduce the issue in a deterministic fashion.  I hope to identify more
information about the circumstances of these errors, but if you have
specific questions, please ask.

Original issue reported on code.google.com by eamon.nerbonne on 2 Nov 2007 at 11:40

[GoogleCodeExporter]

I am curious to undestand if that i just a display issue in the demo 
application (in that case this is probably not 
getting fixed - after all that is a demo app, not a working calendar), or if 
this is an issue in the data returned 
from the server? In that case we have a server bug in the calendar service. 

If you can (assuming you are familiar with that) look into the HTTP data send 
to verify that? if not let me know, 
and i try to get this reproduced locally. 

Original comment by fman...@gmail.com on 13 Nov 2007 at 2:02

• Changed state: Reviewed

[GoogleCodeExporter]

I discovered the issue trying to integrate a different app with google 
calendar. 
It's merely a fortunate test-case that the demo-application also displays the 
same error.

I'll try to find an explicit problem on a public calendar to ease verification.

Original comment by eamon.nerbonne on 13 Nov 2007 at 4:32

[GoogleCodeExporter]

Well, I've narrowed it down. 

There are two separate issue.  One's not an error, but my own mistake:

The api returns no more than 25 events by default.  Since I was querying 
approx. a
three month timespan, this contained more than 25 events.
Perhaps the documentation could be improved however,
http://code.google.com/apis/calendar/developers_guide_dotnet.html#RetrievingEven
ts
makes no mention of such a limitation nor of the "NumberToRetrieve" option
controlling it.

The second issue is that events which don't exist are included in the output.  
This
seems to be a protocol error. Specifically in this case it concerns recurring 
events
published by other authors for which the browsing person has deleted.  I'm not 
sure
if all these circumstances are required.  I've captured the Http traffic 
illustrating
the error for a particular event on my own calendar.  However, the traffic is 
full
authentication and security tokens (of which I'm not sure what they do), and 
I'm not
comfortable with posting it here.  If you think it's useful, mail me.

In any case, the event in question is on the calendar using this gmail name
eamon.nerbonne[at]gmail.com, 2007-10-26 18:30-20:00, and since the calendar is
busy/free viewable to all, you should be able to verify it's absence via the
web-interface yet presence via the protocol.

Original comment by eamon.nerbonne on 14 Nov 2007 at 12:23

[GoogleCodeExporter]

Normally, delete events WILL be in the feed, but they will be marked as 
cancelled. The demo (written long ago 
before that mechanism was developed) does not take this into account. So, my 
question to you is: are those 
events which are still seeing marked with a cancelled=true element? If so, then 
the feed is correct, and you can 
feel free to file a bug against the sample program. Please let me know. 

Original comment by fman...@gmail.com on 14 Nov 2007 at 7:41

[GoogleCodeExporter]

As you say it should be, it's canceled.  

Of course, since the EnumConstruct can't be compared using == (unlike normal C#
enum), mistakes are likely (and documentation would improve things).

I hope my frustrations were more constructive than irritating, but in any case,
thanks for the help, and for the - bug free :-) - API!

Original comment by eamon.nerbonne on 14 Nov 2007 at 8:58

[GoogleCodeExporter]

There is no bug free code :) 

Of course, you are correct, and given the fact that this particular project 
started a long time ago, there are things 
i would do differently today - as always. I am going to resolve this issue as 
by design for now, if you don't 
object. 

Original comment by fman...@gmail.com on 15 Nov 2007 at 11:04

• Changed state: ByDesign