Generally fine with this proposal.

I’m missing a more/better structured planning though, with some clear milestones etc.

Another question worse investigating is regarding the lib linking and expand processes. Those two could be entirely abstracted and performed through generic lib_query “foreach_id” system, which would save us adding two of the three callbacks currently needed for read code. Main issue/work here would be to add handling of deprecated DNA ID Pointers to lib_query, but that should not be a huge work (we already support conditional handling of some pointers for UI data-block pointers, doing the same thing for deprecated ones should be fairly straightforward).

I agree that lib linking and expanding can and should be done using the generic foreach_id system. However, I don't think that we should do both refactorings at the same time. If we decide to do both refactorings separately, the order probably does not matter too much. The difference is that I could start with the decentralization immediately, while you'd probably need to spend some time to make lib linking and expand work with the foreach_id system.

We can also decide that we only decentralize file writing and direct data reading at first.

As for milestones, I'd say that a first milestone would be to get all modifier specific code out of readfile.c.

Once the API is committed, I could also start using it in readfile.c and writefile.c directly. This would simplify the actual decentralization later on.

If we agree on the API, this should be fairly straight forward to do.

My main point is that if we use libquery for linking and expanding, we do not need those two callbacks in IDTypeInfo then. Feels a bit useless and very noisy to add, then remove two callbacks from such a struct.

I do not know how urgent it is for you to move forward on this topic, if needed i can spend a few hours to check how feasible using libquery for this is…

For the next code quality day, I'd like to follow the checklist I added to the main post. Is that ok?

I think updating lib linking and expand to use the new API is a code quality improvement by itself, independent on how we decide to implement it in the future.

I read in the weekly report that @Bastien Montagne (mont29) did some initial investigation to check if it is possible to use libquery for lib linking and expand. It seems to be not straight forward (which is also what I found). Let's discuss how to proceed with this topic, when I'm done with the tasks listed in the main post.

Yeah, am not super happy to have to go through those intermediate steps (since the IDTypeInfo liblink/expand callbacks will likely be removed soon-ish), but I don’t really plan to work on this usage of libquery for those in immediate future, so I'm fine with your plan.

Going ahead with this for the next code quality day sounds good then.