| 25 Mar 2024 |
 jaywink | Is there a clear benefit of getting rid of the json_context though, doesn't seem to add much weight? I mean if you need to, feel free if the purpose can be server otherwise | 20:42:45 |
| jaywink | I do remember it had a bigger function before | 20:42:59 |
 Alain | Well, I didn't say I wanted to get rid of the json_context, it's just that I'm not getting it because it's only sent through Django views which the new UI is not using. | 21:06:47 |
| Alain | The new UI only talks to the API. | 21:07:56 |
| jaywink | yeah that makes total sense 👍️ | 21:09:25 |
| Alain | This will need a little more thinking. I want Django to give me the stream name, but I'm not sure what the best way is. | 21:15:24 |
| Alain | I'll dig in the drf serializers to find out if they implement a way to send some kind of out-of-band data. | 21:24:18 |
| Alain | Or whatever else that does what I need. 🙂 | 21:29:54 |
| Alain | I think I have some learning to do on how the streams viewsets build their responses. | 21:42:25 |
| Alain | I'm thinking maybe wrapping stream responses in the json_context, but that would be a breaking change. | 21:44:43 |
| * Alain is thinking out loud | 21:47:54 |
| Alain | Or attaching the json_context at the end of the json contents array? | 21:54:26 |
| Alain | I was doing an inventory of the websocket endpoints the current UI is using and the tag (not tags) stream names are built with the tag id, which is currently meaningless for the UI (both current and new). | 22:02:06 |
| Alain | I think it's sane to have the backend provide the stream/channel names. | 22:03:32 |
| 26 Mar 2024 |
| Alain | How about using a custom HTTP header? Say socialhome-channel-name? It's trivial to implement and would not break anything. | 15:07:13 |
| jaywink | I guess that could work? Would it potentially break in some reverse proxy configs? | 20:24:12 |
| jaywink | something that strips headers aggressively etc hmm | 20:24:26 |
| jaywink | is there a technical reason it can't be in the index.html or such just out of interest? I think it's a relatively common pattern to provide some bootstrapping info there, though maybe "it was a common pattern" ;) | 20:26:00 |
| Alain | If you go to index.html once and then the SPA takes over, how do you get the channel name when the user clicks on other vue-router links? | 21:15:56 |
| Alain | But, yeah, there's the potential header clean up by reverse proxies or webfilters. | 21:16:52 |
| Alain | Those that strictly follow rfc-2616. | 21:19:26 |
| Alain | I said it's nice to have the backend provide the channel name, but maybe we could address this differently for the SPA. Feom what I can tell, the only websocket endpoint that can't be derived from a route is the tag/<tagname> case because the backend returns tag__tagid__userid. | 21:26:04 |
| Alain | * I said it's nice to have the backend provide the channel name, but maybe we could address this differently for the SPA. From what I can tell, the only websocket endpoint that can't be derived from a route is the tag/<tagname> case because the backend returns tag__tagid__userid. | 21:26:22 |
| Alain | And, unless I'm missed something, the tag ids are not sent with a tag/<tagname> stream. | 21:43:04 |
| Alain | * And, unless I'm missed something, the tag id is not sent with a tag/<tagname> stream. | 21:43:25 |
| Alain | I guess we could make a slight mod to /api/tags by adding the tag ids and have the SPA pull the all the tags once. And the add a ws notification on tag creation. | 21:57:55 |
| Alain | * I guess we could make a slight mod to /api/tags by adding the tag ids and have the SPA pull the all the tags once. And then add a ws notification on tag creation. | 21:58:11 |
| 27 Mar 2024 |
| Alain | Nah. This would be too inefficient. | 11:21:25 |
| jaywink | I must admit I'm having a hard time suggesting something sane due to the code base already being a bit alien 😅 | 16:36:04 |
| 28 Mar 2024 |
| Alain | I'm already beginning to forget the code I wrote for Activitypub support in federation, so I hear you. 😉 | 11:29:13 |
