That's great news... :)
So it looks like I might be able to only use the GetListItemChangesSinceToken
regardless of SP Version... We may want to try the same Query (don't include the changeToken) on SP2010 and SP2013 just to make sure the behavior is the same (meaning: successful)...
Sounds like SP2010 and 2013 tolerates an empty element since it works on those environments. I may be able to do this later tonight or this weekend if you can't...
What I'm working with:
I have had a "module" that provides data Queries that "persist" - meaning: after you get the query "Object" back, that query remains "alive" and monitoring for changes (using pull rather than push - since SP does not
provide for websockets). I was using an ugly approach with GetListItems which had complexities around how to identify item(s) in the Query that no longer matched the criteria (CAML) and thus should be removed from the set... Getting the list of changed or
new items was not difficult, but removes was an issue.
So I'm doing some refactoring into a more robust library... GetListItemChangesSinceToken
is perfect for this module because it does a great job of identifying add/changes as well as deletion from the query. The library I have does more than monitoring
the data, it also allows me to bind "listeners" (events) that are triggered when the Query changes and using
to provide the data as observableArray's and objects who values are observables as well.
As I mentioned, this module uses knockout.js - which ties the query (actually a Knockout.js observable Array with a few more custom methods) to the ViewModel (the HTML UI and thus you have a responsive UI. This works very well in Single Page Applications...
And... I enable this functionality by extending SPServices (without changing the library itself)
to recognize a new input param called 'persist'.... When my code see that and if the operation is GetListItems or GetListItemChangesSinceToken, it handles
the "Query".... If it does not see it, then it just lets it go to SPServices...