+1 to your proposal Chris. Although I also see this more like an ENV variable I would not go as far as to extend mspec for this, even less this close to 1.0.0.
I like that "another option" extending the Config system. With a hierarchy: connection string -> Config -> ENV -> hardcoded Having it on connection settings may make it accessible on integrations where a user may not be able to update ENV. On NiFi for instance. Unai On Thursday, August 20th, 2026 at 2:31 PM, Christofer Dutz <[email protected]> wrote: > As it was pretty atomic and a super-quick thing. > > Here’s my proposal: > https://github.com/apache/plc4x/commit/b84b057368bb69acf456396fd7510081b9263602 > > Chris > > Von: Christofer Dutz <[email protected]> > Datum: Donnerstag, 20. August 2026 um 13:37 > An: [email protected] <[email protected]> > Betreff: How to deal with recursion? > > Hi all, > > I want to introduce a way to limit recursion. Here I’ve been chatting with > Sebastian and we seem to have different opinions on how to do this. > > We somehow have to provide a configurable maximum recursion depth. > This then acts as a safeguard and if this recursion depth is exceeded, then > the parsing stops with an error. > > Now the question is: How would we provide such a value? > > I would like to add it as a connection-string parameter. If I have a device > that needs a higher default, I can increase that device’s parameter … > assuming 99% of my PLCs are ok with the default, but I have this one monster > PLC where it’s not enough. On this machine I then get errors explaining that > the message exceeds the configured max-depth (or however we call it) and the > operator can add a config parameter, that increases this for this connection. > > Sebastian would like to set an ENV variable and extend mspec to read them. > > Admittedly I don’t like this option as it would change the default for all > connections (or all for a given driver). His argument is: You don’t need to > change the program if the defaults are not enough. My argument: The > connection string is THE place to configure connection-related things. > > He also proposed a hierarchy: config option -> ENV -> hard coded > > I would be hesitant to start extending mspec with support for accessing > environment variables or system properties. It’s complex enough already (I > think). > The connection string in my opinion is THE place to make connection settings. > Why add another path to pass in stuff? > > Another option might be to extend the Config system to access environment > variables and system properties (If we decided to support this sort of > passing in arguments, I would prefer this path over making mspec more complex) > > So … what do you folks think? > > Chris > >
