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?
