Open / close ports.

[jfjlaros]

Discussion on #5

[jfjlaros]

An other approach would be to automatically open and close the port for each call. This could be moderated by an extra optional parameter for the constructor.

[chrisflesher]

I added a couple more options, option 4 adds a reopen command. Option 5 adds a is_socket_connection to help handle the special case of ethernet connections. Can you review these and see which one you like the best?

Long term you might think about using context managers for both serial and ethernet connections (similar to option 3). They are nice because if there is an exception raised when communicating it will always close the port at the end regardless of whether or not there was an exception. There is usually no problem opening / closing serial ports frequently similar to ethernet ports (unless you have two programs fighting over it). The downside to option 3 breaks the API significantly, removing the wait and autoconnect options. Most of the other options attempt to preserve the existing API.

[jfjlaros]

Thank you for your hard work. I will try to compare the different approaches before the end of the week.

[jfjlaros]

I prefer option 5 as it takes all the burden away from the user to open/close ports.

I re-implemented your idea using decorators, can you have a look at this branch?

[chrisflesher]

I like the auto_open decorator, it simplifies things. I added your changes to PR #11 and also some changes to reduce latency of function calls for ethernet socket connections. This was necessary because otherwise each function call will take ~5 seconds to complete waiting for _get_methods. Can you see what you think about those? I haven't tested the changes yet.

[jfjlaros]

Wouldn't you get the same effect when wait=0 is passed to the constructor?

[jfjlaros]

Please note that we call self._connection.close in the decorator. The open and close functions are only called once.

[chrisflesher]

There are two separate problems here:

1. The ethernet socket needs to be opened and closed very often for the Arduino code to exit the communications while loop and do other things (e.g. sample and filter sensor data)
2. Each time the port is opened it takes ~5 seconds for the _get_methods(self) function to complete (at 9600 baud with ~20 function definitions). It is not acceptable for my particular project to wait this long for each function call.

By adding decorators we've solved problem 1. Adding wait=0 might help problem 1 but not fix problem 2. The most recent commit I added attempts to solve problem 2 (but maybe could be improved). Does this make sense?

[jfjlaros]

I did not have time to look at your latest commit, I will do this tonight, but I think we agree. In general I have the following flows in mind:

For serial connections:

• open port
• get methods
• do calls
• delete methods
• close port

For sockets:

• open port
• get methods
• close port
• for each call:
  • open port
  • do call
  • close port
• delete methods

If you like, I can draft an implementation of this.

[jfjlaros]

I tried to explain this line of reasoning in this review. Can you have a look?

Perhaps this view is more helpful.

[jfjlaros]

I just submitted a small patch with some comments here.

[jfjlaros]

I just made a branch in which subclasses are used to make things a bit clearer (hopefully).