On Fri, Oct 20, 2023 at 11:29:34PM +0200, Aleksandar Lazic wrote: > > On Fri, Oct 20, 2023 at 11:11:59PM +0200, Aleksandar Lazic wrote: > > > I can't find any doc about entities in the current git > > > > > > alex@alex-tuxedoinfinitybooks1517gen7 on 20/10/2023 at 23:06:19 > > > /datadisk/git-repos/haproxy $ find . -iname "*entities"* > > > alex@alex-tuxedoinfinitybooks1517gen7 on 20/10/2023 at 23:06:27 > > > /datadisk/git-repos/haproxy $ > > > > > > What's my mistake to find this doc? > > > > No mistake, this file was so much outdated that not any single box > > on it existed in recent versions so it was about time for it to > > be removed. It was a bit heartbreaking, but killing a 15-years old > > doc because the architecture evolves is not that bad of a news :-) > > I feel your pain, got similar with appsession years ago :-)
Actually the doc removal was not a pain. Looking at it was. I got used to mentally replace certain parts with others I was aware of, and finally considered that if I was able to replace them I didn't need the doc, and others couldn't use it at all anyway. Another gain we've got in the modern architecture is that, despite having many more layers (due to multiplexing for H2/H3 and transport for QUIC), lots of parts have been standardized with smaller interfaces to the other parts. This means that when working on an applet for example you don't need to know the rest anymore. Similarly it's possible to write a mux by copy-pasting mux-h2 or mux-quic and replacing the control logic and the protocol processing there, without ever having to worry about how upper layers are going to use that. Thus it has become more difficult to hack into the project (due to the large number of features we don't want to break by accident and the resulting complexity) but it has also become much easier to add new features. I remember 20 years ago when we were dreaming of supporting keep-alive and it took several years to arrive (version 1.4). Nowadays it would take less than one week to write a basic HTTP/1 mux supporting this on the frontend side with the level of interoperability we used to support by then (chunks were not supported then and a lot of the advanced security checks were not there). Ideally we'd need to have more internal docs, each focusing on a specific area. We have parts on muxes, layering, scheduling, memory management, htx, filters, event handling, buffer, init calls, lists, ... Like with every forthcoming release I'd like to tidy these parts a little bit, and arrange them between design docs to use for developers and docs to use as reminders of certain use cases, or when debugging. But overall it's not that bad I think, as code always evolves faster than doc anyway. > > I suggest that you have a look at doc/internals/api/layers.txt first, > > then doc/internals/muxes.pdf whicih show the lower layers in boxes > > and what remains of the stream layer on top as the channel. > > Thanks. Will send a patch to fix the doc. OK thanks! Willy
