UNPKG

jinaga

Version:

Data management for web and mobile applications.

jinaga.com

jinaga/jinaga.js

73 lines (49 loc) • 3.68 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
### **Enhancement Proposal** Enhance the Jinaga graph protocol to improve stream continuity and version negotiation using state-based hashing and content negotiation mechanisms. --- ### **Proposed Features** 1. **Version Negotiation**: - Use `Accept` headers and `OPTIONS` requests to negotiate protocol versions between the client and replicator. - The client sends an `OPTIONS` request to the replicator to determine supported protocol versions for the `/save` endpoint. - Ensure backward compatibility by allowing clients to adjust to the replicator's supported versions. 2. **Hash-Based Stream Continuity**: - Replace the use of a graph ID with a state-based hashing mechanism: - The client computes a **starting hash** that represents the state of the graph at the beginning of the `/save` call. - The replicator computes a **final hash** after processing the payload. - If the starting hash of the next `/save` call matches the replicator’s final hash from the previous call, the replicator resumes processing from that state. - In case of a mismatch, the replicator responds with an appropriate HTTP error code, prompting the client to reinitialize its state. --- ### **Implementation Details** #### **Protocol Details** - **Client-Side Changes**: 1. The network manager on the client maintains a single `GraphSerializer` for its communication with the replicator. 2. The client generates a unique starting hash based on the state of the graph (e.g., using a cryptographic hash of the serialized graph state). 3. The `/save` endpoint sends the starting hash along with the serialized graph payload. 4. After receiving a mismatch response from the replicator, the client abandons its current `GraphSerializer` and starts a new one. - **Replicator-Side Changes**: 1. The replicator maintains a `GraphDeserializer` for each active graph stream. 2. The replicator computes a final hash based on the processed graph state at the end of each `/save` call. 3. On receiving a new `/save` call, the replicator validates the starting hash against its stored final hash. 4. If the hashes match, the replicator resumes processing. Otherwise, it returns an HTTP error code (e.g., `409 Conflict`) to signal a mismatch. #### **Content Negotiation** - Extend the `OPTIONS` handler for the `/save` endpoint to include supported protocol versions in the `Accept` header. - Update the client to dynamically select the appropriate protocol version based on the replicator’s response. --- ### **Benefits** - **Resilience**: The hash-based mechanism ensures robust recovery from network interruptions, allowing streams to resume seamlessly. - **Efficiency**: Reduces redundant data transfer by eliminating the need to re-upload predecessors in subsequent `/save` calls. - **Compatibility**: The use of version negotiation allows the protocol to evolve without breaking existing implementations. --- ### **Constraints** - **Stream Exclusivity**: - Ensure that only one active stream exists for a given graph state to prevent parallel processing conflicts. - **Hash Validation**: - Both client and replicator must implement consistent hashing algorithms to avoid mismatches due to serialization differences. --- ### **Next Steps** 1. Define the hashing algorithm and graph serialization format. 2. Implement the content negotiation mechanism in both the client and replicator. 3. Update the `/save` endpoint to include starting and final hashes. 4. Add unit and integration tests to verify protocol behavior under various scenarios. --- Let me know if you need further clarification or additional details for implementation!