Socketcan transport

[Łukasz Dywicki <lu...@code-house.org>]

Hey folks,
I wanted to let you know that socket can stuff which I implemented in
very raw form on top of JavaCAN is working. I been asked by library
author to make it a part of next release of his library. I am fine with
that, but before I will move code anywhere I wanted to check what's your
thinking in this area.

There is already an issue in JavaCAN about netty support:
https://github.com/pschichtel/JavaCAN/issues/20
This issue aims use of netty epoll together with linux epoll on top of
socketcan to implement non-blocking pipelines. If it eventually comes to
this project we'll benefit a lot in high performance scenarios (can fd)
and these where time is important.

My personal perception is that moving what I did to javacan-netty will
let more people utilize this integration and probably improve its
quality over time. If we will hold what I did in house we will block
eventual evolution of this part. After move we will still need dedicated
plc4x-socketcan transport, however its role will be mainly to map URI
parameters to javacan options (which we don't ATM).

Let me know what you think.

Kind regards,
Łukasz

Re: Socketcan transport

[Christofer Dutz <ch...@c-ware.de>]

Hi Lukasz,

I strongly agree that you should donate to that project what you have.

After all we all benefit from it. 

Till that's released however I think we'll keep a copy here and use that.

Thanks for your work on this ... I know CAN has been asked for quite regularly as it seems especially in CNC area this is used a lot.

Chris


Am 01.09.20, 11:55 schrieb "Łukasz Dywicki" <lu...@code-house.org>:

    Hey folks,
    I wanted to let you know that socket can stuff which I implemented in
    very raw form on top of JavaCAN is working. I been asked by library
    author to make it a part of next release of his library. I am fine with
    that, but before I will move code anywhere I wanted to check what's your
    thinking in this area.

    There is already an issue in JavaCAN about netty support:
    https://github.com/pschichtel/JavaCAN/issues/20
    This issue aims use of netty epoll together with linux epoll on top of
    socketcan to implement non-blocking pipelines. If it eventually comes to
    this project we'll benefit a lot in high performance scenarios (can fd)
    and these where time is important.

    My personal perception is that moving what I did to javacan-netty will
    let more people utilize this integration and probably improve its
    quality over time. If we will hold what I did in house we will block
    eventual evolution of this part. After move we will still need dedicated
    plc4x-socketcan transport, however its role will be mainly to map URI
    parameters to javacan options (which we don't ATM).

    Let me know what you think.

    Kind regards,
    Łukasz