Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Public API #6

Open
juniorz opened this issue Mar 21, 2017 · 4 comments
Open

Public API #6

juniorz opened this issue Mar 21, 2017 · 4 comments
Labels
API architecture importance high An issue that is absolutely necessary to have done before final release release
Milestone

Comments

@juniorz
Copy link
Member

juniorz commented Mar 21, 2017

At the moment we have two sets of API:

Protocol API (#include <libotr4/otrv4.h>)

This is the API for "Off-the-Record Messaging Protocol version 4". A protocol manages a connection that allows different versions of the wire protocols defined in the spec (version 3 and version 4). Once two running protocols decide on a wire protocol version, they use it to start a connection by running a key-exchange algorithm.

A connection is able to process incoming zero-terminated *char messages ("strings") from the IM network and decide how to respond to it. Incoming messages may cause a zero-terminated *char message (OTR-encoded "strings") to be send as a response, or contain a *uint8_t plaintext message (array of bytes).

A connection is able to process *uint8_t plaintext message (array of bytes) into a zero-terminated *char message (either OTR-encoded or plaintext message "strings") before sending to the IM network.

Client API (#include <libotr4/client.h>)

This is a "messaging client". A client manages multiple conversations with other recipients/senders, identified by a identity ("[email protected]", for example).

A client knows which conversation to use in order to send/receive zero-terminated *char messages ("strings") to/from a recipient/sender.

@juniorz
Copy link
Member Author

juniorz commented Mar 21, 2017

Questions:

  • Do the actual APIs correspond to the text?
  • Should we extract the connection (or wire) API and make it public?
  • Should a connection be able to send arbitrary array of bytes or only zero-terminated strings?

@claucece
Copy link
Member

claucece commented Feb 2, 2018

For this, should be checked:

  • that everything that should be static is static.
  • separate the internal header files from the API ones.

@olabini
Copy link
Contributor

olabini commented Apr 9, 2018

I have made sure we have the structure for this, but the actual separation of things need to be done. I think we should use development of the plugin to drive this, so probably not something we can do early.

@claucece
Copy link
Member

Yes, this is something to be done right at the end of the libotr-ng work @olabini

@claucece claucece added importance high An issue that is absolutely necessary to have done before final release API labels Jun 26, 2018
@claucece claucece added this to the architecture milestone Oct 20, 2019
@claucece claucece modified the milestones: architecture, May Feb 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API architecture importance high An issue that is absolutely necessary to have done before final release release
Projects
None yet
Development

No branches or pull requests

3 participants