[v0x02] Review the use of "Type"

[diraol]

As we have changes on the Type class (ofp_type) values, we need to review all classes that have had it's types changed on that class.

For example, on the v0x01 version, Type.PORT_MOD value is 15, but on the v0x02 Type.PORT_MOD value is 16, while Type(15) is GROUP_MOD.

So, for all Messages (from GenericMessage) we need to check if its Type has changed on the enum. If it has, then we need to fix it on the message implementation, making sure that the Type is right according to v0x02.

[cemsbr]

I believe Type is one case of many others. We should convert all values to names.

[diraol]

@cemsbr we can have problems with inheritance on that matter.

I'll try to do an example.

On v0x01 we have the Hello message.

It is mainly a header with header.message_type == Type.HELLO, right?

Well, on the v0x02, the Hello message is exactly the same based on this idea.

But, it on v0x01 Type.HELLO have the value of 0and on v0x02 Type.HELLO have the value of 1, then on v0x02 we can't just inherit the Hello message from v0x01. Despite the fact that we are using the name on the class definition.

So, with that, may be we will need to reimplement all messages that the integer value of the "Type" have changed between of versions. Does it seems right for you?

[diraol]

I think that this issue is related to #157 .
If you guys agree, then may be we can close this issue and let the work for that one.

[cemsbr]

Yes, I think re-implementation is the way to go. We should be able to use Enum's field instead of integers.

[diraol]

Actually using the "enum field" does not fix the problem.
For example:

v0x01

>>>class Type_v0x01(Enum):
>>>  HELLO = 0
>>>  ERROR = 1
>>>  ECHO_REQUEST = 2
>>>  ECHO_REPLY = 3

>>>class Type_v0x02(Enum):
>>>  HELLO = 0
>>>  ERROR = 1
>>>  KYTOS = 2
>>>  ECHO_REQUEST = 3
>>>  ECHO_REPLY = 4

>>>Type_v0x01.ECHO_REPLY
3
>>>Type_v0x02.ECHO_REPLY
4

The problem still remains.... the reference will always be to the 'older' version.

[cemsbr]

But if Hello is re-implemented importing v0x02's Type and then we import v0x02's Type when unpacking, there's no problem, right? The unpacking algorithm can remain the same if it uses Enum names instead of values.

[diraol]

Yes! If we re-implement the class there is no problem.

[beraldoleal]

Type_V0X01 is terrible!

[diraol]

@beraldoleal This issue can be closed in favor of #157. Even if we do not change the 'inheritance model', the Type class will be defined within the version module, so this problem will not happen.

@cemsbr do you agree?