<commit_before>Use cases for connection manager capabilities
=============================================

.. contents::

Connection manager capabilities indicate what sorts of channel a connection
manager could conceivably satisfy a request for. This is closely related to
`channel requesting`_, and can be used by clients to decide what UI to
present.

.. _channel requesting: request.html

For instance, Empathy's Chat -> New Conversation menu can use this mechanism
to decide what connection managers could conceivably have what features.

Fundamentally, it is a Connection that has or lacks a particular feature.
However, it would be useful for some part of Mission Control (account manager?
channel dispatcher?) to cache "expected" capabilities for unconnected
accounts, or perhaps even be able to guess what capabilities an account will
have before it has ever become connected.

The current proposal is:

* "Classes" of requestable channel are identified by (ChannelType,
  TargetHandleType) pairs

* If TargetHandleType is not NONE then either TargetHandle or TargetID is
  always mandatory, and TargetHandle (if given) is nonzero

* If TargetHandleType is NONE then TargetHandle and TargetID are forbidden

* Other parameters can be allowed, or not; clients SHOULD NOT send parameters
  that aren't explicitly allowed

Problems with this proposal:

* How do we say that not all "valid" values for a parameter are allowed?
  For instance we might only support a couple of MIME types for file transfer

* Can other parameters can be mandatory? This turns out to be necessary
  (or at least very useful) for File Transfer and Tubes

Optional parameters which could hypothetically apply to all channels
--------------------------------------------------------------------

* ...Channel.Bundle
* ...Channel.Interface.Thread.ThreadID
* ...Channel.Interface.TLS.Secure
<commit_msg>cmcaps issue: can there be more than one "class" per (handle type, channel type) pair?<commit_after>Use cases for connection manager capabilities
=============================================

.. contents::

Connection manager capabilities indicate what sorts of channel a connection
manager could conceivably satisfy a request for. This is closely related to
`channel requesting`_, and can be used by clients to decide what UI to
present.

.. _channel requesting: request.html

For instance, Empathy's Chat -> New Conversation menu can use this mechanism
to decide what connection managers could conceivably have what features.

Fundamentally, it is a Connection that has or lacks a particular feature.
However, it would be useful for some part of Mission Control (account manager?
channel dispatcher?) to cache "expected" capabilities for unconnected
accounts, or perhaps even be able to guess what capabilities an account will
have before it has ever become connected.

The current proposal is:

* "Classes" of requestable channel are identified by (ChannelType,
  TargetHandleType) pairs

* If TargetHandleType is not NONE then either TargetHandle or TargetID is
  always mandatory, and TargetHandle (if given) is nonzero

* If TargetHandleType is NONE then TargetHandle and TargetID are forbidden

* Other parameters can be allowed, or not; clients SHOULD NOT send parameters
  that aren't explicitly allowed

Problems with this proposal:

* How do we say that not all "valid" values for a parameter are allowed?
  For instance we might only support a couple of MIME types for file transfer

* Can other parameters can be mandatory? This turns out to be necessary
  (or at least very useful) for File Transfer and Tubes

* Can there potentially be more than one "class" per pair?

Optional parameters which could hypothetically apply to all channels
--------------------------------------------------------------------

* ...Channel.Bundle
* ...Channel.Interface.Thread.ThreadID
* ...Channel.Interface.TLS.Secure

{'fraction_non_alphanumeric': 0.09966692287983603, 'fraction_numerical': 0.0, 'mean_word_length': 3.973248407643312, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4574905', 'n_tokens_mistral': 899, 'n_tokens_neox': 866, 'n_words': 514}