Outsider looking in; Many language runtimes allows embedding of other languages' runtimes within. So why not pick a languages that is reasonably easy to integrate into other languages, and then write the drivers in a fully fledged programming language, rather than the DFDL abstraction or creating a new DSL with a whole slew of consequences later on.
Languages that might be suitable; JavaScript, Lua, Forth, microPython or even C... Niclas On Mon, Apr 29, 2019 at 2:20 PM Julian Feinauer < j.feina...@pragmaticminds.de> wrote: > Hi all, > > just wanted to sum up some talks and discussions we had off-list about the > whole topic of driver generation / providing drivers in other languages. > Currently, there are the following two approaches going on: > > Driver Generation based on DFDL by Chris: > Chris already shared his branch and is working on the generation of > drivers based on the specification of the messages and a state machine. > This should then generate Code based on Freemarker Templates. > > Proxy Drivers by me, Chris and also others: > We have a thrift based server / client spec. > A simple Java Server is implemented as Interop Server and we work on > providing client in other languages. > This is a separate feature (as Proxy) but in a mode, where the Client > itself starts the server in the background, this is an intermediate > solution to already provide other language bindings (although at a cost). > All work is done in the PLC4X-111 branch and I hope that we will be able > to Merge that soon (Chris spend a lot of effort to include all the new > stuff in our build). > > And there is a new thing coming currently which is mostly Driven by > Matthias and myself regarding the driver code generation. > We went over Chris example code (and the xmls) and our heads nearly > exploded as it is so abstract. > And as Matthias does a lot with model based code generation we had a long > discussion about using a model based approach (probably with a DSL). > So we currently try to investigate that a bit but also with a focus on > research. In fact, we have the potential that we can engage some students > from his institute to participate at the work. > In fact, we even started a private Repo where we prepare a Paper to > discuss the matter. > As this would be our first “PLC4X Paper” everybody is invited to join us > and should simply ping me (with github credentials), to get repo access. > If we make it through we will will of course list everybody who > contributed as author. > > To make it clear, this work, the DSL based driver generation tries to > achieve the same as Chris approach based on DFDL just through another way. > And right now I’m unable to say which one is better, could be better and > where are the drawbacks and advantages. So we want to investigate that to > have a basis for a discussion and decision. In fact, both approaches should > be equally powerful, so one could be able to translate one to the other and > vice versa, in theory. > I consider it highly important to have a good and easy way to develop and > maintain drivers as this is the crucial thing for the future of PLC4X. > > So please feel free to comment or discuss, if you feel like : ) > > Julian > -- Niclas Hedhman, Software Developer http://polygene.apache.org - New Energy for Java
