11:33:36 <damiankloip> alexpott good morning, if you have time, can you take another look at https://www.drupal.org/node/2751325 please? You did review it about 3 weeks ago.
11:33:40 <Druplicon> https://www.drupal.org/node/2751325 => All serialized values are strings, should be integers/booleans when appropriate [#2751325] => 154 comments, 17 IRC mentions
11:34:02 ⇐ AjitS quit (~ajits@103.8.195.26) Remote host closed the connection
11:34:16 <alexpott> damiankloip: yeah I've looked at that several times in the past weeks and alway get icky feelings about the API variance
11:34:43 <damiankloip> alexpott hmmm, what do you mean? Just the switch from timestamps in general?
11:35:37 <alexpott> damiankloip: I mean say two different companies build services for Drupal sites and one demands you have the BC layer in place to connect to it and the other demands you don't use the BC layer.
11:35:39 <navneet0_> mohit_rocks: pong
11:35:51 ⇐ apratt quit (~Thunderbi@72.143.232.109) Ping timeout: 252 seconds
11:36:52 <damiankloip> alexpott fair point, but they would have that same problem now too I think?
11:37:00 → AjitS joined  ⇐ nic-o quit  
11:37:54 <damiankloip> we can only configure this stuff globally
11:38:29 <alexpott> damiankloip: this patch is introducing the switch. no?
11:38:47 <damiankloip> alexpott the switch yes, but I don't see how it hurts needing to implement both
11:39:09 <damiankloip> it just changes the default behaviour?
11:39:19 <damiankloip> you would need custom logic either way to achieve this right now
11:39:27 <alexpott> damiankloip: we have no API versioning - how does a service know?
11:39:46 <alexpott> damiankloip: right now everyone is going to build services that assume all things are strings
11:39:58 <alexpott> damiankloip: this patch opens a future where that is not true
11:39:59 <damiankloip> alexpott if it's an existing site though, the BC will be enabled, so there is no change unless they opt in
11:40:39 <alexpott> damiankloip: but this stuff is meant to be consumed by other sites... the existingness of the site emitting the response doesn't matter
11:41:05 → apratt joined  ⇐ Sutharsan quit  
11:41:25 <damiankloip> right, but if it's a new site, or and existing site opting in to the casting, they would presumably tests this with stuff that needs to consume it?
11:42:40 → claudiu_cristea joined  ⇐ dragos-dumi quit  
11:44:19 <alexpott> damiankloip: you are not in control of your third parties. And this change introduces the possibility of incompatible third parties.
11:44:42 <alexpott> WimLeers: interesting random fail... https://www.drupal.org/pift-ci-job/572255
11:44:46 <damiankloip> alexpott it does, but isn't that why you would just leave the BC in place if you were worried about it?
11:44:53 <damiankloip> that's why we have the config for it
11:45:18 <damiankloip> If someone opts in to this change, they would know they were doing it
11:45:32 <alexpott> damiankloip: but you might one to use more than one third party... and they can have different expectations.
11:45:45 <alexpott> damiankloip: but all new sites get this change.
11:45:49 <damiankloip> alexpott then leave your site emitting strings
11:45:53 <damiankloip> as it is now
11:46:17 <alexpott> damiankloip: arggh... but then the third party service builder as to choose whether to build for bc or non bc sites.
11:46:19 → dragos-dumi joined  ⇐ navneet0_ quit  
11:46:41 <damiankloip> hmmm
11:47:11 <alexpott> damiankloip: one option is to have it as always opt in till D9
11:47:27 <damiankloip> I think most of the time this isn't going to make any difference to consumers tbh
11:47:34 <damiankloip> alexpott so even if the module is newly enabled
11:47:42 <damiankloip> make opt in always explicit
11:47:47 <alexpott> damiankloip: yes
11:47:55 <alexpott> damiankloip: because it is an API change
11:47:58 <damiankloip> alexpott sure, I would be ok with that
11:48:17 <alexpott> damiankloip: it'd be nice to an versioning info to the response too
11:48:19 <damiankloip> alexpott we just change the value in the default config
11:48:44 <alexpott> damiankloip: so someone can build a service that works with both the BC layer and the D9 future
11:49:33 <damiankloip> alexpott not sure where that would have to be handled? so versioning indicating the casting? or just the serializer version in general?
11:50:05 <damiankloip> the serializer is not tied to responses in any way, that's the trouble
11:50:24 <damiankloip> it doesn't have knowledge of them
11:50:32 → navneet0693 joined (~navneet06@14.141.151.206)
11:50:33 <damiankloip> I guess you could pass something in the context data maybe
11:50:40 → Sutharsan joined  ⇐ jurgenhaas quit  
11:52:40 <alexpott> damiankloip: I think we should open a separate issue about versioning. It is a super complex subject.
11:53:05 <alexpott> damiankloip: I think making this always opt-in is the easiest way forward.
11:53:06 ⇐ TheRec quit (toto@drupal.org/user/146860/view) Ping timeout: 240 seconds
11:53:08 <damiankloip> alexpott agree, that needs a lot of thought
11:53:18 <damiankloip> alexpott ok, happy to do that, I will update the patch
11:53:26 <alexpott> damiankloip++
11:53:31 <damiankloip> alexpott++
11:53:41 <damiankloip> alexpott as for the versioning, I like using headers for that
11:53:49 → prestonso joined (~Adium@pool-71-183-89-64.nycmny.fios.verizon.net)
11:53:52 <damiankloip> but it seems a few things moved away from using headers in D8