0.5 Roadmap

[xaviervia]

1. Vocabulary

• Introduction of the term "Morphology" appliable to a certain configuration of the Dispatches.
• Introduction of the term "Answer Dispatch" to identify dispatches with the Verb ANSWER and "Answer Resource" to identify the formalized Resource that accompanies such a Dispatch.
• Introduction of the term "Answer Callback" to identify the actual programming rutine to be executed when the Answer is received.
• Introduction of the term "Application Level Response" and "Protocol Level Response" to differentiate regular Dispatches that are issued after a Dispatch is received by a part of the system from Answer Dispatches.
• Formalization of the term "Emitter" to identify the application resource which generates the Dispatch and instructs the JSTP Engine to process it.
• Introduction of the terms "Local Emitter" and "Remote Emitter" to identify Emitters in reach and out of reach of the Engine.
• Formalization of the term "Transaction ID" to identify the first item in the Token Header.
• Introduction of the three Morphologies as distinct configurations:
  • The Subscription Morphology: after a Dispatch with the BIND or RELEASE methods and an Endpoint Header
  • The Regular Morphology: after a Dispatch with GET, PUT, POST, PATCH or DELETE as methods
  • The Answer Morphology: after a Dispatch with the ANSWER Method and a regulated Resource Header
• Introduction of the terms "JSTP Transport Protocol" and "JSTP Transport Protocol Layer" to identify the array of possible transports in which JSTP can be sent (now known to be mainly plain TCP and Websockets).
• NO Introduction of the term "Virtual Host" to identify valid Host Header values that mark a Dispatch to be forwarded, not over a network, but inside the application to a different JSTP engine.
• Introduction of the term "Subscriptions Table" to identify the list of bound endpoints in an Engine.

2. Syntax

• Introduction of the ANSWER method for answering Status Codes to emitters which are preoccupied with the success of the operation.
• Introduction of a formalization of the Answer Resource in the Answer Morphology.
• Formalization of the first item in the Token as an UUID which identifies the Dispatch in terms of Transaction.
• Introduction of Named Resource Patterns to work like their REST counterparts. This extension includes:
  • Wildcards followed by identifiers: ['...anything'] or ['Book', '*author'] not done
  • Alias Named Resource Items, such as [':name'] or ['Article', ':id']. This are just like the REST ones.
  • And of course the \ escape character in order to escape literal resources with special characters: ['\:afteracolon:'] or ['\...afterall']

2.1 URI

MOVED

• Formalization of the JSTP URI Scheme for easy description of Dispatches. Far for complete but proved to be essential for logging and communication purposes.

---

After that everything got moved to jstp/jstp-engine#2

[xaviervia]

In 1.

• Introduction of the term "Source Dispatch" to identify the Dispatch which Transaction ID the Answer Dispatch features as the first item in the Resource Header.

[xaviervia]

Many additions were performed directly on the specification and this list is outdated.

[xaviervia]

In 3.

• API for the Engine methods changed. Only one argument with a JSTPMessage object. JSTPMessage as the argument #27

This goes for the v0.6 roadmap

[xaviervia]

Forgot the referer Header. In 2.

• Add the referer Header specification as dragging the Emitter Token of all Emitters!

[xaviervia]

In 1.

• The term "Item" denotes an element in a header or subheader that is of array type, ie. Resource Item, Endpoint Resource Pattern Item, Token Item, etc.

Does it?

[xaviervia]

• The term Status Code Range for the 1xx, 2xx, 3xx, 4xx and 5xx ranges.

[xaviervia]

• Introduction of the term Triggering ID to describe the ID given by the Engine to an instance of the callback execution. .

[xaviervia]

DONE