Allow sharing transports between packagers by adding Clone method (BC)

[andig]

Fix #56

This is an alternative approach. It features much smaller api surface but leaves responsibility up to the user to understand the transporter's shared nature.

Note: decide name. Is Clone() sufficiently clear? Maybe Share() or ShareConnection() or maybe WithPackager?

[andig]

Friendly ping @frzifus. This would be really helpful using the module downstream and cross-goroutines. The diff looks bigger than it is as I've moved the ...Client routines above the respective ...Handlers for clarity.

[andig]

Any chance for feedback on this change?

[andig]

Friendly ping. This PR is needed to make a modbus connection usable from multiple goroutines, one per id.

[andig]

ping @frzifus did you get a chance to review?

[andig]

ping @frzifus any chance to take a look? Imho this really is a smallish change, although the diff looks large.

[frzifus]

Since users may initialized handlers without the new... functions, I would consider it to mark it as breaking change. wdyt?

The repository does not have a changelog or similar. Maybe we should introduce something like this as an CHANGELOG.md file?

But I assume thats up to @tretmar @Carelo @guelfey - Or maybe you can ping the right contact person.

[frzifus]

Since tcpTransporter doesnt only contain native values, do we need to add a Clone() method for that too?

[andig]

I'm not sure I understand the question (native values?). The purpose of this PR is to share the transporter. The private asciiTCPTransporter etc transporter fields have been converter to pointers to allow this. I didn't see a case for cloning a transporter.

[andig]

@frzifus does that answer the question? Or is there anything specific to the tcpTransporter that I'm missing?

[andig]

In other words: the tcpTransporter is a pointer now that gets copied.

[andig]

TCP is actually a special case that required adjustments to the packager too, see evcc-io#6

[andig]

Since users may initialized handlers without the new... functions, I would consider it to mark it as breaking change. wdyt?

That's a good point. Not doing so will be obvious due to nil pointer panics, but it's definitely breaking. Since this is the case, I'd be happy to add a more fluent way of passing parameters, too if that would help to move this PR along.

[andig]

If anybody wants to test this, I've created a fork at https://github.com/evcc-io/modbus. Happy to update this PR if interest arises.

[andig]

While is PR is meanwhile severely bit-rotten and for sake of reference, we've been successfully using this with evcc.io for ~3 months now and are happy to report that we can have concurrent Go routines interacting with Modbus devices now using different slave ids.

[hnicolaysen]

First of all, thanks for bringing this up @andig!

This PR was long-forgotten on our side, so thank you for your patience and for reviving this! We would be happy to get this repository up to date and to follow up on this change.

Technically, it looks sound to me. I agree, we should mark it as a breaking change unless we come up with a solution that preserves the previous construction.

For me, the name Clone() is fine as the description tells the user well what is does.

[andig]

Thank you @hnicolaysen for the kind words. Lets please try to get #93 merged, then I can update this PR with the remaining fixes. As @frzifus pointed out- though as minimally invasive as possible- this is still a breaking change. Users of the naked structs will now need to initialise the transporters. Due to this it might make sense to merge this only if you're actually going for a v2 version of the library?

[hnicolaysen]

Hi @andig,

since #93 is now closed, what does it mean for this PR? I'm happy to merge it once the PR match the other underlying changes you made.

I would also make a new release as version 2 to make the breaking change more visible 👍

[andig]

Updated PR. Would be great to see the test result.