Changes between Version 16 and Version 17 of Dev/SearchPushModel

Timestamp:

10/13/10 17:17:50 (3 years ago)

Author:

pferreir

Comment:

--

Dev/SearchPushModel

@@ -13 +13 @@
 == Requirements ==
 
- * An extensible mechanism that allows the creation of "agents" that notify periodically external services about changes occurring in Indico records (conferences, contributions and sub-contributions), processing the information in the way they choose to;
+ * [A] An extensible mechanism that allows the creation of "agents" that notify periodically external services about changes occurring in Indico records (conferences, contributions and sub-contributions), processing the information in the way they choose to;
    * The information doesn't need to be "live", meaning that the size of the notification cycle can be in the order of minutes (as to not affect the response time significantly);
- * A particular "agent" that, using Invenio's `WebUpload`, periodically uploads records that need to be updated;
-   * Similar implementation for CERN Search;
+ * [A] A particular "agent" that, using Invenio's `WebUpload`, periodically uploads records that need to be updated;
+   * [B] Similar implementation for CERN Search;
    * Invenio includes the code for a small "client library" that can be used for this task;
    * Agents should be as configurable as possible;
- * `indico.modules.scheduler`-based jobs (one for each "agent") that invoke the agent "submit cycle", that submits information to remote services;
-   * It should be possible to limit the number of records that is submitted each time by an agent/job (deal with backlog issues?);
- * An administration interface, that allows different instances of different `Agent`s to be created and plugged in to different remote systems;
-   * Additionally, a list of all the agents/tasks, the current "pointer" status, and the dates of the (last) data submission should be shown; details about the last transaction (or a log of them) should be displayed: number of submitted objects, duration of operation, types of submitted objects, etc...;
- * Means of logging and error control, as well as mechanisms that guarantee that no data is lost;
- * A mechanism for the manual export of data (in case of failure and in order to index data that already exists in Indico);
+ * [A] Means of logging and error control, as well as mechanisms that guarantee that no data is lost;
+ * [A] Protection scheme, that grants each agent the equivalent permissions of a user or group (or just to all the available content);
+ * [A] `indico.modules.scheduler`-based jobs (one for each "agent") that invoke the agent "submit cycle", that submits information to remote services;
+   * [D] It should be possible to limit the number of records that is submitted each time by an agent/job (deal with backlog issues?);
+ * [B] A mechanism for the manual export of data (in case of failure and in order to index data that already exists in Indico);
    * It should be possible to specify the date range;
- * Detailed documentation, explaining how to develop such an "agent", and the different phases of the update process;
+ * [C]An administration interface, that allows different instances of different `Agent`s to be created and plugged in to different remote systems;
+   * [D] Additionally, a list of all the agents/tasks, the current "pointer" status, and the dates of the (last) data submission should be shown; details about the last transaction (or a log of them) should be displayed: number of submitted objects, duration of operation, types of submitted objects, etc...;
+ * [D] Detailed documentation, explaining how to develop such an "agent", and the different phases of the update process;
    * Likewise, documents that explain the migration process, for an Indico instance;
- * Protection scheme, that grants each agent the equivalent permissions of a user or group (or just to all the available content);