-
Notifications
You must be signed in to change notification settings - Fork 1
Specify split chunks #426
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
base: main
Are you sure you want to change the base?
Specify split chunks #426
Changes from all commits
2008683
6773573
b111a99
67963a9
ad53192
8058e47
681e07c
9da13fa
ab8d4af
f9947ad
78ff6c2
d7b4dbd
f976863
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,7 +9,9 @@ This client is now subscribed to any changes to <<PartitionAdded.newPartition>> | |
|
|
||
| [horizontal] | ||
| .Parameters | ||
| [[PartitionAdded.newPartition, `newPartition`]]newPartition:: <<chunkType>> | ||
| [[PartitionAdded.newPartition, `newPartition`]]newPartition:: <<shallowChunkType>> | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see no reason to introduce a new type for this, we can (as we already did) use the << chunkType >> for this, with the explanation we already had, saying that the containments, references and annotations are empty.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We use it at more than one place, so I'd like to unify the description.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. At all other places I found it used in the spec, I don't think it should be there, as I said in several comments. |
||
| NOTE: This parameter differs from the <<AddPartition.newPartition, corresponding command parameter>>: | ||
| The command's parameter contains a whole subtree, whereas the event's parameter only contains the partition node. | ||
|
|
||
| [[PartitionAdded.originCommands]]originCommands:: <<commandSourceType>>[] | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,27 @@ | ||
| [[cmd-ChunkedCommand]] | ||
| ==== Chunked Command | ||
| A <<continuedChunk>> for one of the following <<splittableMessage, splittable>> commands: | ||
|
|
||
| * <<cmd-AddPartition>> <<AddPartition.newPartition>> | ||
| * <<cmd-AddChild>> <<AddChild.newChild>> | ||
| * <<cmd-ReplaceChild>> <<ReplaceChild.newChild>> | ||
| * <<cmd-AddAnnotation>> <<AddAnnotation.parent>> | ||
| * <<cmd-ReplaceAnnotation>> <<ReplaceAnnotation.newAnnotation>> | ||
|
|
||
| .Technical name | ||
| `ChunkedCommand` | ||
|
|
||
| [horizontal] | ||
| .Parameters | ||
| [[ChunkedCommand.chunk, `chunk`]]chunk:: <<chunkType>> or <<shallowChunkType>> | ||
enikao marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| The continued chunk. | ||
| MUST adhere to the same constraints as the related <<splittableMessage>>'s chunk. | ||
|
|
||
| [[ChunkedCommand.continuedChunkCompleted, `continuedChunkCompleted`]]continuedChunkCompleted:: <<continuedChunkCompletedFlagType>> | ||
|
|
||
| [[ChunkedCommand.continuedChunkSequenceNumber, `continuedChunkSequenceNumber`]]continuedChunkSequenceNumber:: <<continuedChunkSequenceNumberType>> | ||
|
|
||
| [[ChunkedCommand.commandId]]commandId:: <<commandIdType>> | ||
| Id of the related <<splittableMessage, splittable command>> | ||
|
|
||
| [[ChunkedCommand.protocolMessages, `protocolMessages`]]protocolMessages:: <<protocolMessagesType>> | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,27 @@ | ||
| [[evnt-ChunkedEvent]] | ||
| ==== Chunked Event | ||
| A <<continuedChunk>> for one of the following <<splittableMessage, splittable>> events: | ||
|
|
||
| * <<evnt-PartitionAdded>> <<PartitionAdded.newPartition>> | ||
| * <<evnt-ChildAdded>> <<ChildAdded.newChild>> | ||
| * <<evnt-ChildReplaced>> <<ChildReplaced.newChild>> | ||
| * <<evnt-AnnotationAdded>> <<AnnotationAdded.newAnnotation>> | ||
| * <<evnt-AnnotationReplaced>> <<AnnotationReplaced.newAnnotation>> | ||
|
|
||
| .Technical name | ||
| `ChunkedEvent` | ||
|
|
||
| [horizontal] | ||
| .Parameters | ||
| [[ChunkedEvent.chunk, `chunk`]]chunk:: <<chunkType>> or <<shallowChunkType>> | ||
| The continued chunk. | ||
| MUST adhere to the same constraints as the related <<splittableMessage>>'s chunk. | ||
|
|
||
| [[ChunkedEvent.continuedChunkCompleted, `continuedChunkCompleted`]]continuedChunkCompleted:: <<continuedChunkCompletedFlagType>> | ||
|
|
||
| [[ChunkedEvent.chunkedEventSequenceNumber]]chunkedEventSequenceNumber:: <<event-sequence-number>> | ||
| Sequence number of the related <<splittableMessage, splittable event>> | ||
|
|
||
| [[ChunkedEvent.sequenceNumber]]sequenceNumber:: <<event-sequence-number>> | ||
|
|
||
| [[ChunkedEvent.protocolMessages]]protocolMessages:: <<protocolMessagesType>> |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| [[qry-ChunkedQueryResponse]] | ||
| ==== Chunked query response | ||
| A <<continuedChunk>> for a <<splittableMessage, splittable>> response of one of the following queries: | ||
|
|
||
| * <<qry-SubscribeToPartitionContents>> response <<SubscribeToPartitionContents.contents>> | ||
| * <<qry-ListPartitions>> response <<ListPartitions.partitions>> | ||
|
|
||
| .Technical name | ||
| `ChunkedQueryResponse` | ||
|
|
||
| [horizontal] | ||
| .Response parameters | ||
| [[ChunkedQueryResponse.chunk, `chunk`]]chunk:: <<chunkType>> or <<shallowChunkType>> | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I find it very bad practice to have a property with a join type. Also, I do not see why we need << shallowChunkType>> here. All chunks are full << chunkType >>'s |
||
| The continued chunk. | ||
| MUST adhere to the same constraints as the related <<splittableMessage>>'s chunk. | ||
|
|
||
| [[ChunkedQueryResponse.continuedChunkCompleted, `continuedChunkCompleted`]]continuedChunkCompleted:: <<continuedChunkCompletedFlagType>> | ||
|
|
||
| [[ChunkedQueryResponse.continuedChunkSequenceNumber, `continuedChunkSequenceNumber`]]continuedChunkSequenceNumber:: <<continuedChunkSequenceNumberType>> | ||
|
|
||
| [[ChunkedQueryResponse.queryId, `queryId`]]queryId:: <<queryIdType>> | ||
| Id of the related <<splittableMessage, splittable query>> | ||
|
|
||
| [[ChunkedQueryResponse.protocolMessages, `protocolMessages`]]protocolMessages:: <<protocolMessagesType>> | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -73,20 +73,76 @@ The repository also sends out the same events to subscribed clients, thus _not_ | |
|
|
||
| [[message, message]] | ||
| === Message characteristics | ||
| Each message is atomic; it cannot be split. | ||
|
|
||
| [[messageAtomicity]] | ||
| .Atomicity | ||
| Most messages are atomic; they cannot be split. | ||
| The exceptions are <<splittableMessage, splittable messages>>. | ||
|
|
||
| [[messageIdentity, message identity]] | ||
| .Message identity | ||
| Each message has some id unique to the <<participation>>: | ||
|
|
||
| * Queries have a _query id_. | ||
| * Commands have a _command id_.{fn-org305} | ||
| * Events have _command sources_.{fn-org306} | ||
| * Queries have a <<queryIdType>> (for <<qry-ChunkedQueryResponse>> together with its <<continuedChunkSequenceNumberType>>). | ||
| * Commands have a <<commandIdType>> (for <<cmd-ChunkedCommand>> together with its <<continuedChunkSequenceNumberType>>).{fn-org305} | ||
| * Events have <<eventSequenceType>>.{fn-org423} | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And respponses have a unique |
||
|
|
||
| [[technicalName, technical name]] | ||
| .Technical name | ||
| Every kind of message has a unique _technical name_. | ||
| The technical name is a valid programming language identifier as described for <<{m3}.adoc#IKeyed, IKeyed>>. | ||
| Each binding to a specific protocol might use the technical name in a different way. | ||
| For example, a JSON binding might have a member containing the technical name of the message, or a Protobuf binding might use the technical name as type name. | ||
|
|
||
| Each message optionally can have one or more _[[protocolMessage, protocol message]]protocol message_ consisting of:{fn-org331}{fn-org332} | ||
| [[splittableMessage, splittable message]] | ||
| ==== Splittable messages | ||
| All messages containing a <<chunkType>> or <<shallowChunkType>>. | ||
|
|
||
| A client or repository CAN decide to split up a _splittable message_ if that message would exceed the acceptable message size. | ||
| LionWeb does not define the acceptable message size, it SHOULD be a parameter for each implementation. | ||
|
|
||
| All _splittable messages_ contain a <<splitFlagType>>. | ||
| If the flag is `false`, the splittable message is self-contained. | ||
| If the flag is `true`, one or more <<continuedChunk>> messages will follow.{fn-org425} | ||
|
|
||
| _Splittable messages_ include: | ||
|
|
||
| Queries:: | ||
| * <<qry-SubscribeToPartitionContents>> response <<SubscribeToPartitionContents.contents>> | ||
| * <<qry-ListPartitions>> response <<ListPartitions.partitions>> | ||
|
|
||
| Commands:: | ||
| * <<cmd-AddPartition>> <<AddPartition.newPartition>> | ||
| * <<cmd-AddChild>> <<AddChild.newChild>> | ||
| * <<cmd-ReplaceChild>> <<ReplaceChild.newChild>> | ||
| * <<cmd-AddAnnotation>> <<AddAnnotation.parent>> | ||
| * <<cmd-ReplaceAnnotation>> <<ReplaceAnnotation.newAnnotation>> | ||
|
|
||
| Events:: | ||
| * <<evnt-ChildAdded>> <<ChildAdded.newChild>> | ||
| * <<evnt-ChildReplaced>> <<ChildReplaced.newChild>> | ||
| * <<evnt-AnnotationAdded>> <<AnnotationAdded.newAnnotation>> | ||
| * <<evnt-AnnotationReplaced>> <<AnnotationReplaced.newAnnotation>> | ||
|
|
||
| [[continuedChunk, continued chunk]] | ||
| .Continued chunks | ||
| _Continued chunks_ continue the chunk from the related <<splittableMessage>>. | ||
| Each _continued chunk_ refers to the <<splittableMessage>> it belongs to. | ||
| The _continued chunk_ contains a chunk, a consecutive sequence number, and a <<continuedChunkCompletedFlagType>> to signal whether it is the last _continued chunk_, or more will follow. | ||
| If the flag is `true`, this is the last _continued chunk_. | ||
| If the flag is `false`, one or more _continued chunk_ messages will follow.{fn-org425} | ||
|
|
||
| There MUST NOT be any message in the same <<channel>> between the _chunked message_ and all related _continued chunks_. | ||
|
|
||
| _Continued chunks_ include: | ||
|
|
||
| * <<qry-ChunkedQueryResponse>> | ||
| * <<cmd-ChunkedCommand>> | ||
| * <<evnt-ChunkedEvent>> | ||
|
|
||
| [[protocolMessage, protocol message]] | ||
| ==== Protocol messages | ||
| Each message optionally can have one or more _protocol message_ consisting of:{fn-org331}{fn-org332} | ||
|
|
||
| * [[protocolMessage.kind]]`kind` is an <<{m3}.adoc#identifiers, identifier>>-compatible string identifying the message type. | ||
| Some message kinds are pre-defined in this specification. | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.