Based on my own doubts and Ingo's feedback I've decided to not base
OperationSetBasicInstantMessagingTransport on
OperationSetBasicInstantMessaging. Even though it doesn't make much
sense to implement BasicInstantMessagingTransport and not
BasicInstantMessaging. In theory we could at least query the
characteristics if not actually use the protocol, so I've decided to
extend OperationSet directly.
for querying protocol implementation for operational boundaries.
* Defined the Operation Set for querying transport operation.
* Also implemented the Operation Set in IRC protocol support.
* OTR plugin has been modified to take advantage of the newly defined
Operation Set and queries the protocol for input on building
fragmentation instructions. In case the protocol does not implement the
Operation Set, then it will fall back to OTR defaults.
Modifications include the following:
- Updated otr4j which includes support for fragmentation of outgoing
messages. The modifications to otr4j to enable outgoing message
fragmentation includes breaking the API such that we are able to
return more than 1 message after it has been transformed.
(Corresponding modifications have been made to
AbstractOperationSetBasicInstantMessaging to facilitate the new API.)
- Fixed IRC implementation for OperationSetInstantMessageTransform.
- Modified AbstractOperationSetBasicInstantMessaging to handle multiple
Events returning from a call to messageTransform.
- Modified OperationSetBasicInstantMessaging implementations to
correspond to changes in AbstractOSBIM.
- OTR plugin has been modified to implement the newly added
getFragmenterInstructions method which is used to query instructions
on desired fragmentation behaviour.
- As a temporary solution, a hard dependency has been added to IRC
library such that I'm able to test fragmentation behaviour in a real
use case until an OperationSet is defined that can be used to query
for Instant Messaging transport parameters necessary to determine
appropriate fragmentation instructions.