Actions
Task #2612
closed
Implement Sync Update Processor
Status:
Closed
Priority:
Normal
Assignee:
-
Category:
ndn-atmos-catalog
Start date:
03/02/2015
Due date:
% Done:
0%
Estimated time:
Description
- informed of new state(s) by ChronoSync
- verify state change Data packet(s) (async op)
- on accept
- retrieve changes
- verify change Data packets (async op)
- on accept
- apply changes to local catalog via Sync Update Executor
- on reject
- assertion failure
- on reject
- retry
Files
Updated by Anonymous over 9 years ago
- Blocked by Task #2611: Implement Sync Update Executor added
Updated by Chengyu Fan over 9 years ago
- File PublishAdapterClass.jpg PublishAdapterClass.jpg added
The attachment is the UML diagram for PublishAdapter (the current implementation for the publication process).
I use PublishAdapter for the sync update, because
- the ChronoSync requires callback function to process the updates and validator when applications use the ChronoSync library, and the callback's job is to decide whether to fetch the listed missing data, I think a function is good enough to do the job;
- the publishAdapter is tightly associated with the "sync processor", e.g., when the PublishAdapter fetches the data and verify it, it injects the data into the local DB, and then needs to notify other sync nodes by publishing it over ChronoSync;
- for the Sync Update Executor, I'm not sure if it should be a separate class, I think its job is the data insertion, and the publishAdapter contains the data insertion as well.
Correct me if I'm wrong.
Updated by Anonymous over 9 years ago
- Blocked by deleted (Task #2611: Implement Sync Update Executor)
Updated by susmit shannigrahi over 9 years ago
- Status changed from Resolved to Closed
Actions