Hi,

I agree mspec certainly simplifies the implementation and it works well.
Some work around updating the documentation would certainly help out
though. Then again how many people are actually working with the mspec.

I do think that we can do a better job of advertising how quickly custom
protocols can be implemented on the website as it is one of our main
features. It might help to grow the number of people working with mspec.

Ben

On Fri, Jan 8, 2021 at 6:23 AM Christofer Dutz <[email protected]>
wrote:

> Hi Lukasz,
>
> do you really think mspec is a "show stopper"? ... cause I thought of it
> more as a "game changer" and an "enabler".
> Cause let's face it: writing drivers for protocols is not a simple task.
> With mspec I think we have reached a simplicity that I haven't seen
> anywhere before in this sector. And I think seeing that some of our new
> contributors could just checkout and learn from the exising examples and
> produce their own mspecs in a short amount of time, proves that it's
> actually a pretty powerful tool.
>
> I think the protocols you were working on we simply just a nightmare to
> start with ... no tool will help you with such a task and make the bad
> dreams go away. Perhaps if you wrote the dirvers manually you would have
> been quicker in case of CAN.
>
>  I agree that we could need a beginners guide, but currently just don't
> have the time to write one. I did submit talks and workshops to multiple
> CFPs now and I hope that from this I'll be able to prepare some content
> that we can use or even that some recordings might come out of it, which we
> can link.
>
> And regarding your complaint about using Maven excessively: I agree in the
> beginning I tried to mavenize the non-java parts, but if you actually had a
> look recently, that had changed more than a year ago.
>
> Right now every non java part uses the build system native to that
> language:
> - PLC4C uses CMake
> - PLC4CPP usses CMake
> - PLC4Py (the initial version) uses the Python build system
> - PLC4Go uses go
> - In my feature/PLC4Net branch you can use the default .Net build system
> to build
>
> Even the default directory stuctures were mostly used.
>
> You can even develop in PLC4Go, PLC4C, PLC4C++ by just opeining your IDE
> of choice in that particular Language. So I don't quite get the point of
> your complaint.
>
> Yes: in order to generate a new driver in any of these languages, you also
> need to setup maven in order to generate the code. I even reduced the
> problems here by checking in the generated code for C and Go. So you really
> only need to run the maven build to generate, if the mspecs change or you
> want to add a new driver. The other reason for the Maven integration is
> simply to have the builds run in Jenkins. Of course we could not do that
> and setup a Zoo of jobs, each building part of the project, but as I'm
> currently the only one actually taking care of these plumbing tasks,
> I'didn't want to do that (And I could see for other projects how bad this
> actually works)
>
> You could probably change the requirement to run the maven
> code-generation, but for that you would need to implement the
> code-generation for those languages/build-systems. Feel free to do so, if
> this is an itch you feel needs scratching.
>
> What do you others think about this?
>
> Chris
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Łukasz Dywicki <[email protected]>
> Gesendet: Freitag, 8. Januar 2021 00:23
> An: [email protected]
> Betreff: Re: Reflecting on how we volunteer to do stuff
>
> Its low part of the season. People got locked down in their homes (Poland
> just entered new year with another lockdown, Germany is same AFAIK), so I
> am not yet worried by "slowdown" you observe.
>
> I am prime example of someone who has more will that abilities to
> contribute. You know I stayed around since long time and eventually made
> few contributions. I think there might be few more like me. I agree with
> you that making an open community (I think we are) and opportunity to
> contribute is necessary to give dopamine shots we all need.
>
> Now - in terms of low hanging fruits. I saw very few successful
> initiatives such this. Main reason why they fail is .. well, people are not
> often not even aware of them. Making them listed somewhere in JIRA does not
> help (how often do you look in github 'need helps' issues?).
> Its mainly about making entry point easier for people who use project.
> I know how much effort it was for you to help with Ethernet/IP. You
> personally helped me with almost every mspec related contribution I made so
> far. I believe that our main "show stopper" is the mspec. Even existing
> project staff don't know how to start with it or have troubles with it. If
> we could publish beginner guide to mspec that could turn into more people
> trying to write their protocols.
>
> Also we use heavily Maven. While it simplifies life for us (java folks) it
> makes problems for everyone else. I recall Bjorn complaining about it for
> C(#/++?) stuff. Not all people know how to use it, especially if they are
> not from old Java landscape.
> Our docs are dug under maven folders making it hard to contribute docs.
> Maybe pulling it up could help.
>
> This are just my free thoughts on how to make it easier.
>
> Cheers,
> Łukasz
>
> On 07.01.2021 10:28, Christofer Dutz wrote:
> > Hi folks,
> >
> > I'd like to discuss something ... something I have been noticining in
> the last year or so.
> >
> > We're a cool bunch of people, doing awesome stuff. However momentum in
> the project has sort of slowed down quite a bit. I know we have some great
> new initiatives going on, but let's say it's become a bit quiet around the
> folks which have been involved for a longer time period.
> >
> > I would like to get more people involved and active in the project.
> Therefore I would like to strart posting low-hanging fruit here on the list.
> >
> > In the past when I did so, the community was quite fast in raising hands
> and volunteering to do things. However volunteering is one thing, actually
> doing seems to be something else. In my impression we could improve on the
> delivering side. I know we are a volunteer driven community and you are
> therefore contributing voluntarily in your free time or in the time your
> company is paying you. But ... keep in mind:
> >
> >
> >   *   If you volunteer to do something, probably others will not raise a
> hand to also contribute. If you now don't deliver what you signed up for,
> the others won't either.
> >   *   If you volunteer to do something, I will think that this base is
> covered and not jump in (I don't want to interfere in every initiative, but
> I am happy and willing to help if help is needed)
> >
> > So could you please do me a favour?
> >
> > If I start posting some low-hanging fruit in the near future, please
> consider if you will also have the time to actually do so, before signing
> up?
> >
> > Chris
> >
>

Reply via email to