Wed, Feb 21
@JoeWalsh is the big issue for you about having to try 500 individual requests if the entire batch fails fail?
@Tgr given your plan to implement batching internally (insert all records at once), is this still possible?
Wed, Feb 14
Yeah it sounds like we are trying to use EL “the wrong way”
Mon, Feb 12
Ok, I'll chat about this with Sam today, but I think we have some pretty clear things to do:
Wed, Feb 7
@Tgr it seems like syncing for apps can be simplified to just using changes since endpoint, if we enable this behavior of passing "0" (distant past). The other REST APIs are still needed for Web and other applications, but this should at least solve the issue of getting the first time stamp.
Tue, Feb 6
Fri, Feb 2
Thu, Feb 1
Wed, Jan 31
Thanks for putting all this together…
Tue, Jan 30
Cool, thanks moving to the Kanban board then
@Tgr this came out of the need for supporting client side ordering - this seemed reasonable to me, does it look ok to you as well?
Here are some distilled notes from the session.
Mon, Jan 29
Jan 17 2018
Some opt my own thoughts and some cribbing from the ATWG sessions:
Jan 16 2018
Waiting on CSS development to start… blocking on that
Jan 10 2018
@daniel potentially… there is definitely a desire to be able to reliably parse information from main pages, news portals, features article pages, etc…
Jan 9 2018
Ok, that didn't take long… I am re-wrong again 🤦♂️
@RHo I talked to the iOS team about this today also. I had a misunderstanding of how the Default lists were identified by the server. They are identified simply by the name property, so the service does need to make sure that it rejects setting the name to "Default" for any list that is not the actual default list. Thanks for being on top of this…
Yes, this is now supposed to be in the payload. Good catch - feel free to update and repurpose this ticket for that
Jan 8 2018
@bearND something we didn't discus and should be covered here, but just to highlight:
Jan 5 2018
Jan 3 2018
Dec 20 2017
Dec 13 2017
Dec 11 2017
@C933103 Just an FYI, this is only for APIs, not for user facing web URLs.
Dec 7 2017
Dec 5 2017
Dec 4 2017
@Tgr dropping them is all cool… those were old design ideas that never materialized…
Nov 30 2017
Nov 29 2017
Just a note deployment, if we want to get this deployed this week, we need to finalize everything today or tonight. We have 2 deployments left:
@schoenbaechler We can update the button text, there is no facility to update the button style in the apps.
Nov 28 2017
@Tgr thanks for hopping on this. We already talked, but writing here to document: Batching is blocking for client adoption, but you don't need to block pushing the service to production, if it is easier to think about the batching solution first. Lets be sure to get it in ASAP either way, the app teams will need this API to do testing - which will be performed this month and next with a projected production release in January.
Nov 27 2017
Hey all, following up here after the holiday.
Nov 15 2017
No, the news is unavailable we probably need top split up this ticket. Since featured article is resolved but news is not.
Nov 14 2017
Tagging app projects for visibility
Nov 13 2017
@mobrovac that is not any type of assurance that would happen… sorry if that is confusing. We should not plan on this returning to production.
Nov 9 2017
@Mholloway something I just noticed… sorry for all the last minute things…
@phuedx Hey looking at the spec for type… we have the following:
@Mholloway can you confirm the comment I just made? Does that seem right as a list of things to do?
So the things I see that we need to do (if the response is up to date)
Nov 7 2017
@Tgr just to follow up on your comment on the need to use OAuth: The requirement comes from legal... basically as way to remove the liability of being responsible for handling user credentials.
I’m adding @Anomie here who has a lot of insight into authorization in MediaWiki
Brad, do you have any insight into the issue here? Seems like that code is pointing to an invalid OAuth Key