You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 30, 2022. It is now read-only.
I am guessing it's not doing this because it isn't pulled out by the propertylist since the response for this property does not include a propstat tag.
Additionally, is this the most logical way to work with these responses? Having statuses as child of the href I assume makes sense when the href represents the address book, but when working directly with contacts as in sync, each href will only have 1 status, which makes these return values look a little odd. I can work on improving this (or working with it as is) if you think it's the most sensical way of working with these responses, but otherwise I'll implement something new if you think this could be improved.
Note: the multistatus response also includes a sync token which is ignored by this method, I am thinking of adding a parseSyncToken or parseSyncMultiStatus method that will pull all of this out. An example of what I have working so far returns something like this:
but I am still undecided whether this is the way to go, whether the array should be inverted like this, whether to use clark notation for the href / etag, and whether the href should simply be the key (although this makes processing adds/deletes separately a little more faff.
Thoughts appreciated.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
@evert I am doing some work with sync-tokens and sync-collections, and working through some issues with multistatus responses.
When I have an XML response like this:
The parseMultiStatus method of the existing client is giving me a response like:
Should it not have at the very least:
I am guessing it's not doing this because it isn't pulled out by the propertylist since the response for this property does not include a propstat tag.
Additionally, is this the most logical way to work with these responses? Having statuses as child of the href I assume makes sense when the href represents the address book, but when working directly with contacts as in sync, each href will only have 1 status, which makes these return values look a little odd. I can work on improving this (or working with it as is) if you think it's the most sensical way of working with these responses, but otherwise I'll implement something new if you think this could be improved.
Note: the multistatus response also includes a sync token which is ignored by this method, I am thinking of adding a parseSyncToken or parseSyncMultiStatus method that will pull all of this out. An example of what I have working so far returns something like this:
but I am still undecided whether this is the way to go, whether the array should be inverted like this, whether to use clark notation for the href / etag, and whether the href should simply be the key (although this makes processing adds/deletes separately a little more faff.
Thoughts appreciated.
The text was updated successfully, but these errors were encountered: