Kaladaran/briar
0
0
Fork 0
mirror of https://code.briarproject.org/briar/briar.git synced 2026-02-14 11:49:04 +01:00
Code Issues Projects Releases Wiki Activity

akwizgran created page: ClientApiNotes

akwizgran
2015-12-07 14:32:46 +00:00
parent 5334d66307
commit 6ccc275f0b
1 changed files with 12 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
ClientApiNotes.md

@@ -1,7 +1,9 @@
[BSP](BSP) clients may need to store their own metadata as well as the data they sync via BSP. Metadata may be extracted from the data (e.g. the subject line of a message), or it may describe the state of the client (e.g. whether the user has starred a message). It may refer to a single message or the relationships between messages. We have to decide whether the metadata should be stored in the same database as the data, and if so, what the API for storing and querying metadata should look like.
[BSP](BSP) clients may need to store their own metadata as well as the data they sync via BSP. Metadata may have been extracted from the data (e.g. the subject line of a message), or it may describe the state of the client (e.g. whether the user has starred a message). It may refer to a single message or the relationships between messages.
We have to decide whether the metadata should be stored in the same database as the data, and if so, what the API for storing and querying metadata should look like.
Issues to consider:
* Encapsulation - if clients have low-level access to the data store they can't be insulated from each other
* Encapsulation - if clients have low-level access to the sync layer's database they can't be insulated from each other
* Modularity - if we want to release the protocol stack as a separate library it should have a well-defined API, not all of SQL
* Expressiveness - if we provide an API for metadata it must be rich enough that clients don't need to use a separate database
* Performance - if we provide an API for metadata it must have comparable performance to using a separate database
@@ -23,20 +25,22 @@ Considering the above issues and uses cases, my current thinking is as follows:
* Ditto, also retrieving the metadata value
* Queries can be scoped to a single channel or all the client's channels
* The sync layer needs to know about dependencies between messages
* Dependencies are included in the message body (opaque to the sync layer) rather than the header, because signatures etc may need to cover them
* When the client validates a message, it parses the dependencies and informs the sync layer
* When a message is shared, the sync layer transitively shares its dependencies
* References between messages are encoded in the message body rather than the header
* References belong in the body because signatures etc may need to cover them
* The body is opaque to the sync layer
* When the client validates a message, it parses the body and informs the sync layer of the dependencies
* Not all references between messages have to be dependencies
* When a message is shared, the sync layer transitively shares its dependencies
* The client can flag expired messages
* The sync layer garbage collects expired messages that aren't transitive dependencies of any unexpired messages
* The sync layer garbage collects expired messages that aren't transitive dependencies of unexpired messages
Sketch of how full text search would work:
* The client parses each message and extracts search words
* The client creates a metadata key for each search word
* The metadata value is a list of positions where the word appears in the message
* One metadata query finds all messages matching a word
* Boolean operators are handled by the client (we could push this down to the metadata API later if useful)
* To search for the phrase "foo bar", use two queries to get the metadata values for "foo" and "bar", manually combine the results to find message IDs where position("foo") + 1 == position("bar")
* Boolean operators are handled by the client (we could push this down to the sync layer later if useful)
* To search for the phrase "foo bar", use two queries to get the message IDs and metadata values for "foo" and "bar", manually combine the results to find message IDs where position("foo") + 1 == position("bar")
* This could be done with a single join query in SQL, so it doesn't score perfectly on expressiveness or performance
Sketch of how attachments would work: