C-toxcore: Implémenter le paquet de capacité client

D'accord. Ma suggestion.

Comme vous le savez (peut-être), le premier paquet qu'un pair envoie à un autre (ou reçoit d'un autre) est PACKET_ID_ONLINE. Ce paquet a une longueur de 1 octet (y compris l'identifiant du paquet). Ma suggestion est d'envoyer les capacités du client dans ce paquet. De plus, Isotoxin le fait déjà. Malheureusement, le noyau actuel ignore ce paquet si sa taille n'est pas de 1 octet. C'est pourquoi, Isotoxin envoie ce paquet deux fois : une longueur de 1 octet pour la compatibilité et une longueur complète avec des informations de capacité.

Qu'en est-il du format de capacité ? C'est juste une chaîne simple avec le format : key:valuen

Chaîne de capacité actuelle de l'isotoxine :
options.client_capabilities = "client:isotoxin/" SS(PLUGINVER) "\n"
"support_bbtags:b,s,u,i\n"
"support_viewsize:1\n"
"support_msg_chain:1\n"
"support_msg_cr_time:1\n"
"support_video_ex:1\n"
"support_folder_share:1\n";

Si une telle méthode ne vous dérange pas, je peux faire des relations publiques.
Ou proposez votre solution. Mais rappelez-vous que le client doit connaître les capacités d'un autre client dans le premier paquet, sinon il sera difficile de comprendre si le client prend en charge le paquet de capacités, ou si ce paquet n'a pas encore été reçu.

Bonne idée, je ne vois un problème que lorsque nous obtenons beaucoup de capacités, la taille des paquets peut être une limite. Cela peut probablement être contourné en envoyant plus de paquets, mais cela nécessite une réflexion.

client_capabilities doit être une structure, comme les options 1, pour la cohérence. J'aimerais voir quelque chose comme :

/**
 * We assume every bool to be false if not specified.
 **/
struct Tox_Client_Capabilities {
  /**
   * The client name, lower case alphanumeric, no spaces. Dash allowed.
   */
  const char *client_name;

  /**
   * The client version, using Semantic Versioning. ie. `0.1.7`, `3.8.0-beta`, etc.
   */
  const char *client_version;

  /**
   * True if the client supports ToxMe/ToxDNS/QNL lookups.
   */
  bool supports_lookup;

  /**
   * True if the client supports ToxID sharing.
   * <strong i="7">@see</strong> Antox and Toxygen
   */
  bool supports_id_sharing;

  /**
   * True if the client supports ToxIdenticons.
   * <strong i="8">@see</strong> Ricin
   */
  bool supports_tox_identicons;

  /**
   * True if the client supports BBCode rendering.
   */
  bool supports_bbcode;

  /**
   * True if the client supports Markdown rendering.
   */
  bool supports_markdown;

  /**
   * True if the client supports audio calls.
   */
  bool supports_audio;

  /**
   * True if the client supports video calls.
   */
  bool supports_video;

  /**
   * True if the client supports file transfers.
   */
  bool supports_files;

  /**
   * True if the client supports inline images transfers.
   */
  bool supports_inline_images;

  /**
   * True if the client supports avatars.
   */
  bool supports_avatars;

  /**
   * True if the client supports message splitting.
   */
  bool supports_messages_split;

  /**
   * True if the client supports whateveryouwantoaddtothatlist.
   */
  bool supports_whatever;
}

client_capabilities devrait être une structure

Mauvaise idée. Et si je proposais une nouvelle fonctionnalité unique ? Dois-je d'abord approfondir les relations publiques pour étendre cette structure ? Non! Seul un ensemble de chaînes avec une standardisation progressive. Sinon, cela ne fonctionnera pas.

Veuillez donc utiliser un format standard. JSON, Yaml, TOML, tout ce que vous voulez mais quelque chose de standard. :)

Je préférerais que le format soit un détail de mise en œuvre. Ce serait bien si toxcore pouvait l'analyser et fournir une API de type clé/valeur (par exemple all_capability_keys , value_for_key ).

Je suis d'accord avec @dvor toxcore ne devrait pas avoir besoin d'analyser les clés et les valeurs, de cette façon les clients peuvent implémenter leurs propres trucs.

Ma proposition pour ce genre de paquet :

[Fixed length binary Header] ... for client capability messages longer than one packet
key=value\n
...

L'en-tête sera quelque chose comme le nombre de segments comme uint16 et le numéro de segment comme uint16.

Les caractères autorisés pour la clé seront [a-zA-Z0-9_] . Les caractères autorisés pour la valeur seront tout sauf \n et = . Les données binaires seront encodées en base64.

Le noyau actuel n'accepte que PACKET_ID_ONLINE d'une longueur de 1 octet.
Ma proposition est d'utiliser ce fait comme séquence de fin de capacité.
L'ancien noyau envoie un PACKET_ID_ONLINE sur 1 octet et le nouveau noyau l'interprète comme la fin de la séquence, donc aucune information de capacité n'est reçue.
Le nouveau noyau envoie le nombre de PACKET_ID_ONLINE avec des capacités avec le dernier PACKET_ID_ONLINE de longueur de 1 octet. L'ancien noyau n'accepte que PACKET_ID_ONLINE sur 1 octet et fonctionne normalement. Le nouveau noyau concatène tous les PACKET_ID_ONLINE > 1 octet et fournit des informations complètes sur les capacités au client.

avantages:

• Compatibilité totale entre les anciens et les nouveaux cœurs
• Le client peut accéder aux informations de capacité uniquement dans tox_callback_friend_connection_status
• Isotoxin utilise déjà ce schéma (sauf concaténation)

les inconvénients:

• ?