Geee ... another reply I didn't get ... I wonder if it's you'r email address that's causing issues with my email filter ... will investigate.
On 2026/08/20 13:44:40 QuanticPony wrote: > +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 > > > > >
