In a recent message to the tech@ mailing list, Omar Polo (op@) asked for comments or oks for a patches implementing a change of table protocols. A little later, Gilles Chehade (gilles@) posted the backstory to the misc@opensmtpd.org mailing list with the backstory for this change.
The message follows in full below (apparently the otherwise fine marc.info archive site no longer archives the list):
Date: Fri, 03 May 2024 08:22:03 +0000
From: gilles@poolp.org
To: misc@opensmtpd.org
Subject: smtpd: change the table protocol
Hello,
This is a copy of a mail I sent to OpenBSD hackers a few days ago so you are aware of work
being done on OpenSMTPD by Omar Polo.
~~~
TL;DR: proposal to change table backends wire protocol to one that's closer to filters, it
has proven to work for years now, comes with many benefits and it is a very trivial
change that we can pull in a handful of hours:
https://tmp.omarpolo.com/smtpd-tables.7.html
Four weeks ago in the 14-th TWIF we announced the start of 1.20 testing and the repository management improvements that it brings. Over the years, the concept of a “repository archive” kinda stayed the same. Basically, instead of serving the users the full list of all the versions of all the apps, we give them only the latest three versions for each app, as users will just update to the latest one anyway. This keeps an index update easy to download, and this was improved again a couple of years ago by offering diff-updates (not the full index, just the difference compared to your local index), so if you update once a week you’ll end up downloading 200Kb or less.
Since the Archive will collect old versions continuously, its size grows each cycle, and the index as expected, making working with it a heavy task for your device. For this reason we don’t encourage its use unless it’s really needed, eg. for running on old Android versions, and to disable it when done.
As the Client focus is to draw users to the actual main repo, and not to emphasis the Archive, with the latest repository management design it was decided to treat Archive as an option that users can toggle on, instead of having a separate repo entry. This toggle is in the repo details, “in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’“, 🙂 oh, I mean under the mirror list. This list is under a work in progress redesign of its own, so it’s a bit finicky to scroll right now, leaving even astute Android users to wonder how an Archive can be added or used.
To be fair, the linked Fedi post above has this information in the first picture, but we understand that we’ve looked a lot at these strings and we are biased to consider them “good enough”. One reason to test these changes as early as possible is to gather feedback from users. If you have thoughts on a better wording, feel free to ping us.
Aurora Store was updated to 4.4.4 and will deemed stable in the next-next index update. You can update now manually if you wish.
Grazer Linuxtage Schedule has changed its application identifier due to some, ahem, alternative centralized store policy. Its users are advised to uninstall and install the new app aptly named: Grazer Linuxtage
NewPipe is reproducible again and was updated to 0.27.0 fixing a lot of bugs users were waiting for months already. We hope future versions get delivered faster.
0.5 to 0.60.8.6b1 to 0.8.7b11.4.5 to 1.4.61.3.8 to 1.3.91.3.3 to 1.3.41.2.0 to 1.2.10.4.1 to 0.4.214 to 150.0.8-0-g4c8399ad to 0.0.9-0-g8dc513560.0.8-0-g4c8399ad to 0.0.9-0-g8dc513560.0.8-0-g4c8399ad to 0.0.9-0-g8dc513560.0.8-0-g4c8399ad to 0.0.9-0-g8dc513560.0.8-0-g4c8399ad to 0.0.9-0-g8dc513560.0.8-0-g4c8399ad to 0.0.9-0-g8dc513560.0.8-0-g4c8399ad to 0.0.9-0-g8dc513560.0.8-0-g4c8399ad to 0.0.9-0-g8dc513560.0.8-0-g4c8399ad to 0.0.9-0-g8dc513560.6.20 to 0.6.221.0.58 to 1.0.611.5.5 to 1.5.63.3.0 to 3.4.02.7.0 to 2.8.01.2.8 to 1.3.020240412-01 to 20240419-010.16.8 to 0.16.93.21.0 to 3.21.10.5.0 to 0.5.12.1.0-beta.5 to 2.1.0-rc.01.2.11 to 1.2.120.10.8 to 0.10.91.7.2 to 1.7.32024.1 to 2024.2-beta13.8.2 to 3.8.2.10.9.15 to 1.0.03.29.0 RC1 to 3.29.020240421 to 202404240.9.9.84 to 0.9.9.9018.1.0 to 19.0.01.1.5 to 1.1.61.0.19 to 1.0.191.2.46 to 1.2.474.9.0 to 4.9.23.4.1 to 3.4.21.2.0 to 1.2.1v0.5.5e to v0.5.5g1.4.6 to 1.4.81.21 to 1.21.13.193.9 to 3.194.03.7.0 to 3.8.00.0.5 to 0.0.61.6.0 to 1.6.210.9.1 to 10.10.15.0.0/X to 5.0.1/X6.20.1 to 7.0.00.62.0 to 0.62.22.7.3 to 2.7.4220.240411.0 to 225.240417.04.11.6 to 4.11.7-patch11.0.9 to 1.0.110.38.1 to 0.38.21.8.1 to 1.8.220.0.0.0 to 20.0.1.01.10.0 to 1.10.12.5.0 to 2.6.01.4.13 to 1.4.142.5.6 to 2.5.718.1.0 to 19.0.02.07.04.ose to 2.07.05.ose1.5.4 to 1.5.53.12.3-beta to 3.12.4-beta2.8.0 to 2.8.255881 to 55883Thank you for reading this week’s TWIF 🙂
Please subscribe to the RSS feed in your favourite RSS application to be updated of new TWIFs when they come up.
You are welcome to join the TWIF forum thread. If you have any news from the community, post it there, maybe it will be featured next week 😉
Author: Source Read more
Navigation module makes use of Layout Builder to construct the navigation toolbar.
There have been some questions about this decision in Slack. This post discusses the background.
In #3397058: Convert navigation sections to blocks and use the menu system the navigation module added a plugin system and config entity for ‘navigation blocks’. These were very nearly identical to block plugins and block config entities. The primary difference was the config entities did not depend on a theme like block config entities do.
In #3411099: Create an administration UI for managing Navigation Blocks a UI was added for editing and managing navigation blocks. This duplicated further code from the block module.
#3438895: Add the new Navigation to core as an Experimental module was the issue to add the navigation module to core. This point was the first time that many core committers had looked at the code. As part of a Framework Manager review of the issue, the amount of duplication between the block and navigation modules was raised.
Until this point the navigation module lived in contrib and did not have a chance to change code in core. But now that it was a merge request against core, changing core was a possibility. As a result the Framework Managers made an attempt to modify the theme-assumption in the block system to support the navigation use-case. This resulted in a less than ideal scenario where Block::getTheme() could return null or an empty string in some scenarios. Whilst it was possible to fix all calls in core, the impact this could have on contrib and custom code felt like it would be problematic.
At this point the idea of using Layout Builder’s section storage as a data-model for the blocks in navigation was floated. Layout Builder’s section storage provides a data-model that allows placing and configuring block plugins but without block config entities. There is no dependency between these block placements and a theme. Layout Builder also includes an API for limiting which blocks can be used where, which was also a requirement for the navigation module. Not all block plugins would work inside the navigation toolbar.
The Framework Managers worked on the core merge request to assess the feasibility of this change. The net result was the removal of 4,000 lines of code but with largely the same functionality. As a result, the version of the navigation module that was committed to Drupal 10.3.0 and 11.x depends on the Layout Builder module.
Sites who don’t use Layout Builder for building entity displays can continue to use their preferred approach. Having Layout Builder enabled doesn’t change how entities are rendered unless you enable it on a per entity-bundle-display basis. Prior to 10.3 there were performance issues from the number of block plugins derived by Layout Builder. But from 10.3 sites can now control and prevent this.
The Navigation initiative has created a list of follow-up issues for the usability of Layout Builder when configuring the navigation toolbar. Some of these overlap with existing usability issues for Layout Builder. In addition the recently announced Experience builder initiative will invest in improving Layout Builder usability. Finally, the Dashboard initiative is also using Layout Builder for handling block placements. When we standardise on a solution and work together to improve it, it will lead to improvement across the board.