I agree, I intentionally didn't respond as I didn't do any of the design decisions you were referring to, so I felt a bit unqualified to answer ;-)
How about you do the changes on a branch and we discuss the changes then? Chris -----Ursprüngliche Nachricht----- Von: Julian Feinauer <[email protected]> Gesendet: Donnerstag, 15. April 2021 12:28 An: [email protected] Betreff: Re: RFC / Tooling SPI for drivers / connection state tracking 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> >
