1) Message Context.
In this solution, I would not return
detailed fields too ... That's why I said "as Kai explains : MessageContext.equals()
is used for matching". So we are agree on this point.
Ah, they were only listed to get an idea of
the members. Yet it also looked like a single class to
me. I would go for:
interface MessageContext
class UDPMessageContext (with remote socket address,
nothing else)
class DtlsStrictMessageContext (which uses epoch next to
the other stuff)
class DtlsFlexibleMessageContext (which uses ciphersuite
etc.) – let’s look for a better name ;)
Did you mean you don't see the semantic
dependency ? If you forget the CoAP use case how
did you choose what you put in the MessageContext ? or
what is compared in MessageContext.equals() ?(This is the
same thing for me)
The instance of the MessageContext is
produced by the connector that knows the specific
fields. In the unlikely case someone uses
element-connector alone, the application gets it from
UDPConnector. When an application uses Scandium, it
configures the mode and then gets the instance from
DtlsConnector.
The context is nothing random in CoAP. A
UDP socket address is a classic message context. So is
DTLS session epoch. If an application needs something
exotic like our flexible DTLS mode, we can consider
adding it, if it makes sense.
I think we are agree on the way
we could implement this solution ... what I tried to
show you is the semantic dependency issue.
(which is not a big one if we consider that
element-connector and scandium aim only/mainly CoAP
protocol.)
Sorry, I still don’t see the dependency
issue :)
Did I miss something? Or does my explanation above make
sense?