Hi Lukasz, this is a response not only to this thread but also tot he previous one.
Frankly, I have to admit that we did not an in-depth architecture session when creating all those classes so I’m pretty sure there are some things which can be done better. One general topic why I decided to choose classes over instances was that it works also for classes which would decide to store state (which would be a total upfuck otherwise) AND that we have this „auto injection of properties“ which ist he major point. But those are generally rather week points so I would not object a refactoring there at all. When we worked on the StackConfigurer we did it the way to support what was there an das CAN is kind of a new beast we SHOULD see where we need to generalize again to make it work. And I also agree with what you say about reporting connection issues back tot he driver. This is a powerful feature that I think makes a lot of sense. So TL;DR; Go ahead, you got my support. And no, we did not consider every case that you bring up now : ) Best Julian On 2021/04/14 13:55:36, Łukasz Dywicki <[email protected]<mailto:[email protected]>> wrote: > I need an clarification and/or have request for change in our API/SPI.> > This is closely related to further CAN bus work I plan to do, but not> > only. I do see that what Ben did few weeks ago with connection tracking> > is very interesting to move forward.> > At present we do not offer end user an API to react on connection> > shutdown or failure. There is no way for him to find that ie. link died> > and his program needs to take action.> > > What I currently also do not understand/lack clearance is how stack> > configurer interacts with TCP connection. Here what bothers me:> > - Is there a new stack/decode instance per each active connection?> > - What is was intended design for driver context and why it is> > inaccessible via PLC connection interface?> > > I suppose that stack per connection is desired case, but if that's true> > why we pass classes and instead of creating instances in stack configurer?> > My case here is intended to attach connection state listener but also an> > message listeners which could help debugging message exchanges. All> > without tapping into wire.> > > A default way we advertise is making PCAP recordings> > which is fine for development. What I look for is an "logging" interface> > to be used in production or test environments without necessity to get> > libpcap involved. This would allow creation of additional tools if needed.> > > Best,> > Łukasz> >
