Expand library for more transports

[splatch]

Recently I had a look on CAN-over-ethernet as I was forced to do a remote debug of some CAN communication.
I realized that it is not that hard to make basic client of socketcand as I was able to do that using telnet client. This made me curious if we could get other drivers which would work under Windows and not require native libraries. I started to look at other known CAN drivers/transports/interfaces out there such as slcan and gs_usb. I think these are not that far away and could be implemented. Effectively it would open JavaCAN to wider pool of users who are stuck to Windows.

I am not certain if it would fit into idea of JavaCAN as for now this project is strictly speaking focused on socketcan bridge. It will bring also more dependencies (ie. serial port handling).
I wouldn't want to implement that in Apache PLC4X cause its internal transport mechanism is bound to netty which complicates a lot basic protocol work.

What your take on that?

[pschichtel]

I like the idea and I did think about that in the past, but it definitely complicates things. JavaCAN is currently very strongly focused on socketcan. However this doesn't mean that other transports couldn't live under the same JavaCAN umbrella in additional modules, possibly reusing some core bits and pieces.

As part of #38 I also thought about further restructuring of the current module structure to support both the cross-compiled JNI approach and project panama at the same time.

I think the abstractions as they are now are not well suited for reuse in other transports, but that could be something to be worked towards once we have a first version of another transport.

What would be the first protocol you'd go for?

[splatch]

Hey Phillip,
Thanks for fast answer. I am aware that bounding between socketcan and JavaCAN is present. I don't really mind it cause it gave this project a structured approach. The CanFrame is good enough for beginning, requires minor adjustments I believe. BCM and ISO-TP support you made is also an interesting area which appears in socketcand.

I think that first one I would try is socketcand as it is just a TCP read/write interface for socketcand. It can be done with fairly basic socket client, without extra dependencies. It also solves my immediate need to have a remote access to can interface with diagnostics software. I would put other implementation for later, if we get over socketcand. I have few ucan devices dongles (yet another fork of candleLight), their firmware can be swapped to slcan and cross tested under windows.

One thing I noted while playing with socketcand is the timing information which is provided as part of frame which is currently not supported by API (see #5):

rcv: < hi >
snd: < open can0 >
rcv: < ok >
snd: < rawmode >
rcv: < ok >
rcv: < frame 738 1652295808.477464 05 >
rcv: < frame 738 1652295808.479889 058A010000000000 >
rcv: < frame 728 1652295809.835495 05 >

(receive frame format is < COB sec.usec data >, not sure about sending as I didn't go that far.

[pschichtel]

I think a better approach for this would be a layer on top of JavaCAN

[pschichtel]

if I tackle this, it will come with breaking changes to the API, so javacan 4.