At some point we may want to organise supported schemas into groups depending on the application they are required for. This could then be use to configure replication behaviour in a more fine grained, per-application manner. This would have an impact on on Announce, TargetSet composition and sync session establishment, our configuration flow.
For example, a fantasy config file would look like:
[[applications]]
name = "My mushroom app" # A name I give the application
schema_ids = ["sighting_0020...", "species_0020..."]
storage_allowance = 20 # MB storage allowance
[[applications]]
name = "My video sharing app"
id = ["huge_video_file_0020...", "favorite_videos_0020..."]
storage_allowance = 10000
This config would result in the node producing 2 Announce messages, and starting separate sync sessions for each set of application schema. Whether blob_v1 and blob_piece_v1 were included in each announce/target set would be different for each application and depend on their individually configured storage allowance.
At some point we may want to organise supported schemas into groups depending on the application they are required for. This could then be use to configure replication behaviour in a more fine grained, per-application manner. This would have an impact on on
Announce
,TargetSet
composition and sync session establishment, our configuration flow.For example, a fantasy config file would look like:
This config would result in the node producing 2
Announce
messages, and starting separate sync sessions for each set of application schema. Whetherblob_v1
andblob_piece_v1
were included in each announce/target set would be different for each application and depend on their individually configured storage allowance.