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" <l...@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
