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...


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

Reply via email to