The purpose of this discussion is to determine how sided logic should be handled on Tesla. This issue is a mix between #6 and #7 along with some extra discussion. This discussion will remain open until may 11th 2016. Extensions may be given if further discussion is required. A straw poll will be opened one day before the deadline to allow voting on solutions. The highest voted submission will be implemented.

What is currently agreed upon

• EnumFacing parameters from ITeslaHandler are redundant and should be removed.
• All sided logic should be handled in the hasCapability and getCapability methods.

Current issue
How should the function of a side be determined? The current capability merges the idea of a producer, consumer and holder into one. Because of this, it is impossible to tell the difference between an input face and an output face.

Solution 1
A new method can be added to the ITeslaHandler which will allow a handler to tell other things what a side should be used for. The return type would support Input, Output, Both and neither.

Pros

• Solves the issue without splitting the main capability into three different ones.

Cons

• Requires other mod authors to check if the side is valid on their end.
• Requires the capability instance to be obtained before making the check, which can be unnecessarily inefficient.

Solution 2
Split the component into three different components based on producer, consumer and holder roles. Each capability can then be checked for and handled directly by the hasCapability and getCapability methods.

Pros

• Gives the holder of the capability all control over it's access. If it does not want a face to be used as an input it can refuse to give access.
• The thing accessing the capability holder is not responsible for checking if a side is valid before using it.
• Specialized tesla handlers have less useless code.

Cons

• Requires the capability holder to manage additional capabilities if they want all in one access.
• Code for wrappers and handlers would be slightly more complex. Especially for sided wrappers.
• Huge change in direction from the current code which will require existing Tesla mods to redesign their code.

I'd definitely rather see multiple Capabilities rather than one capability trying to handle everything. (Similar to how RF handles it's interfaces)

I personally think Solution 2 would be better in the long run since with that, if two mods make cables... you can deny input or output from a certain side, the other mod can pick that up with ease and then not make the cable render as connected or be connected at all. if that makes any sense.

PR #12 is the current candidate for resolving this solution. When it has a net of 10 thumbs up it will be merged.