I've noticed some hidden features of mspec when I declared a `Duration` field type and surprisingly - it did compile because of wildcard import from javax.time. :-)
Using implicit classpath is fine for me. I haven't done the active part of the LLDP, but I suspect that overlapping part with profinet will be just structures. The big differentiator is how actually frames are processed. Cheers, Łukasz On 11.05.2020 14:48, Christofer Dutz wrote: > Hi Lukasz, > > well in the PLC4J 0.6.0 world we explicitly modeled each layer of the > protocols so they could be layered. > However we quickly noticed that not a single layer was re-used. > > I agree that the current mspec approach brings some duplication with it, > however I am not really seeing it happen so far. > I would assume as soon as we start supporting more CIP based protocol, the > duplication will increase. Same with the low level ethernet frames. > In theory it should be quite simple to just add wildcard import statements to > a driver which should make it work with layered mspecs. > The reason this should work is that currently the parser doesn't check if all > used types are actually defined, it just expects the developer to take care > of this. > > For now I would suggest to keep it simple and duplicate things and as soon as > we see problems arise from this, we can factor out the common parts. > > What do you think? > > Chris > > > > > Am 11.05.20, 14:01 schrieb "Łukasz Dywicki" <[email protected]>: > > Hey, > Based on observations I gathered while writing LLDP and Profinet DCP > mspec file I found there are some elements which are repeating between > these. > These are basic structures: mac address, ip address and ethernet frame > with different payloads based on ethernet type field. The same > structures must be added to LLDP, Profinet DCP and eventually any other > raw ethernet protocol. > Since I do see a risk of getting growing amount of code duplicated > across a project I wanted to discuss possible approaches to that. I do > not see a big trouble around mspec, cause above structures are all > together 15-20 lines long, but around processing of ethernet frame itself. > Because same interface can host multiple protocols I am not quite sure > how to proceed with this one. So far we have only SingleStack configurer. > I been thinking about basic unification and re-use of Ethernet frame > across low level protocols. Maybe it would allow us to provide a > multistack configurer implementation. > I am aware that the same interface can be opened by pcap library > multiple times, however I do see an overhead there. Multiple handles > will keep processing same packets with no real need for that. > > Please take this as a starting point for a discussion as I do not have > any idea yet, how to handle this. If you do - then please throw it here. > :) > > Best, > Łukasz >
