[jitsi-dev] RFC: New Operation Set for querying protocol's transport characteristics


#1

Hi all,

I'd like your feedback on this proposal for a new operation set:
Operation Set Basic Instant Messaging Transport.

This operation set is defined for querying operational data on a
protocol's transport channel of a particular basic instant messaging
implementation. It can be used to query the boundaries and other
properties of this particular transport such that we can discover its
characteristics. Obviously, the Operation Set may be extended with
similar methods.
On a side note, by providing a new operation set that extends from
OperationSetBasicInstantMessaging it makes the implementation optional,
so it will not disturb protocol implementations that have no need for it.

Specifically for my use case, OperationSetBasicInstantMessagingTransport
is used to query the IRC protocol implementation for its maximum
supported message size in order to provide reliable message
fragmentation for the OTR plugin. In the case of IRC, its transport
supports messages of at most 512 bytes. Of these 512 bytes, 2 bytes are
used for the message ending (CRLF) and the message itself contains a
command and the receiving contact's address, which is variable in
length. Furthermore, the IRC server will prefix the message with the
identity string of the sender which contains a host name. All in all, we
need to compute how much capacity there is actually left for the
"payload", i.e. the actual message.

The (initial) version of the Operation Set can be found here:
https://github.com/cobratbq/jitsi/blob/otr-fragmentation/src/net/java/sip/communicator/service/protocol/OperationSetBasicInstantMessagingTransport.java

The application of the operation set within the OTR plugin can be found
here:
https://github.com/cobratbq/jitsi/blob/otr-fragmentation/src/net/java/sip/communicator/plugin/otr/ScOtrEngineImpl.java#L429

I'd like to push the changes in a few days and will take into account
the feedback that I get from this.

Kind regards,
Danny


#2

I'm not sure if extending the ImOpSet is the way to go (as opposed to being just standalone), but in any case the method names could be a bit more clear, e.g.:
- getMaxMessageChunkSize
- getMaxNumberOfConsecutiveMessages or getMaxNumberOfMessageChunks

And by Transport we usually referred to the underlying protocol (UDP/TCP/TLS) a Jitsi protocol implementation uses, but I don't have a better suggestion for the OpSet name atm...

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

Le 26.09.2014 à 03:10, "Danny van Heumen" <danny@dannyvanheumen.nl> a écrit :

I'd like your feedback on this proposal for a new operation set:
Operation Set Basic Instant Messaging Transport.

This operation set is defined for querying operational data on a
protocol's transport channel of a particular basic instant messaging
implementation. It can be used to query the boundaries and other
properties of this particular transport such that we can discover its
characteristics. Obviously, the Operation Set may be extended with
similar methods.
On a side note, by providing a new operation set that extends from
OperationSetBasicInstantMessaging it makes the implementation optional,
so it will not disturb protocol implementations that have no need for it.

Specifically for my use case, OperationSetBasicInstantMessagingTransport
is used to query the IRC protocol implementation for its maximum
supported message size in order to provide reliable message
fragmentation for the OTR plugin. In the case of IRC, its transport
supports messages of at most 512 bytes. Of these 512 bytes, 2 bytes are
used for the message ending (CRLF) and the message itself contains a
command and the receiving contact's address, which is variable in
length. Furthermore, the IRC server will prefix the message with the
identity string of the sender which contains a host name. All in all, we
need to compute how much capacity there is actually left for the
"payload", i.e. the actual message.

The (initial) version of the Operation Set can be found here:
https://github.com/cobratbq/jitsi/blob/otr-fragmentation/src/net/java/sip/communicator/service/protocol/OperationSetBasicInstantMessagingTransport.java

The application of the operation set within the OTR plugin can be found
here:
https://github.com/cobratbq/jitsi/blob/otr-fragmentation/src/net/java/sip/communicator/plugin/otr/ScOtrEngineImpl.java#L429

I'd like to push the changes in a few days and will take into account
the feedback that I get from this.

Kind regards,
Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Hi,

I'm not sure if extending the ImOpSet is the way to go (as opposed to being just standalone), but in any case the method names could be a bit more clear, e.g.:
- getMaxMessageChunkSize
- getMaxNumberOfConsecutiveMessages or getMaxNumberOfMessageChunks

I can go with getMax..., however calling it a 'chunk' might not express
the right idea, since basically it's the maximum size of a protocol's IM
message. 'chunk' might lead people to look for another
meaning/interpretation that isn't there.

And by Transport we usually referred to the underlying protocol (UDP/TCP/TLS) a Jitsi protocol implementation uses, but I don't have a better suggestion for the OpSet name atm...

I noticed. This is kind of a difficult thing, since basically it is the
correct name. E.g. TCP and TLS aren't on the same level either. I
thought of 'Protocol' but that's even more of a loaded concept,
especially for Jitsi, so that one's out. We could go with
'Infrastructure', but that's broad term too.

I think that 'Transport' is so far the best suited name. If I go with
the name, I'll be certain to review the javadoc to make sure that the
intention is clearly stated such that it won't cause additional confusion.

Danny

···

On 09/26/2014 03:45 AM, Ingo Bauersachs wrote:

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

Le 26.09.2014 à 03:10, "Danny van Heumen" <danny@dannyvanheumen.nl> a écrit :

I'd like your feedback on this proposal for a new operation set:
Operation Set Basic Instant Messaging Transport.

This operation set is defined for querying operational data on a
protocol's transport channel of a particular basic instant messaging
implementation. It can be used to query the boundaries and other
properties of this particular transport such that we can discover its
characteristics. Obviously, the Operation Set may be extended with
similar methods.
On a side note, by providing a new operation set that extends from
OperationSetBasicInstantMessaging it makes the implementation optional,
so it will not disturb protocol implementations that have no need for it.

Specifically for my use case, OperationSetBasicInstantMessagingTransport
is used to query the IRC protocol implementation for its maximum
supported message size in order to provide reliable message
fragmentation for the OTR plugin. In the case of IRC, its transport
supports messages of at most 512 bytes. Of these 512 bytes, 2 bytes are
used for the message ending (CRLF) and the message itself contains a
command and the receiving contact's address, which is variable in
length. Furthermore, the IRC server will prefix the message with the
identity string of the sender which contains a host name. All in all, we
need to compute how much capacity there is actually left for the
"payload", i.e. the actual message.

The (initial) version of the Operation Set can be found here:
https://github.com/cobratbq/jitsi/blob/otr-fragmentation/src/net/java/sip/communicator/service/protocol/OperationSetBasicInstantMessagingTransport.java

The application of the operation set within the OTR plugin can be found
here:
https://github.com/cobratbq/jitsi/blob/otr-fragmentation/src/net/java/sip/communicator/plugin/otr/ScOtrEngineImpl.java#L429

I'd like to push the changes in a few days and will take into account
the feedback that I get from this.

Kind regards,
Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev