## Please put instances of this task in the subfolder Tasks/ with name for the number, and subfolders as approproate, e.g. Tasks/X/Y ## If any of the below links or sections are not applicable to your page, then please comment them out rather than deleting ## as they may become relevant later on. ## Headline like "Task Implement Backup" = Task DOMS Client = ## Task title Title:: DOMS Client ## Valid states: "Not started", "In progress" and "Finished" State:: Not started ## The time used is measured in man days and does not include the time spent on any sub-tasks. As a rule of thumb, time should always be allocated to subtasks, rather than parent tasks. Format: Xmd Time used:: ## As time used Time estimated:: == Description == The DOMS Client java library will be utilized by (for now) four other components of DOMS: * Summa integration * DOMS GUI * Mass ingest * OAI-PMH So the features of the DOMS Client library should atleast facilitate whatever these four components need from the lower levels of DOMS. A brainstorm on interactions with these four "users" of the DOMS Client can be found in the Analysis Document below. Most of the functions of the DOMS Client can be implemented as methods on java objects which represent their Fedora object counterparts. This will allow the DOMS Client users to juggle DOMS contents in a convenient object oriented way. These methods manipulate object graphs in Fedora and deal with views, collections, relations, content models, datastreams, object status, and so on. These are mainly used by DOMS GUI and Mass Ingest. A few methods needed in the DOMS Client will not belong on Fedora object representations - these instead "slice the Fedora contents by time", generating bundles of objects modified since a certain date/time, for use by Summa integration and for providing OAI-PMH access. The complexity of most methods mentioned in the analysis is low to medium, with a few methods with higher complexity (like generating recent-change bundles and compound content models). The methods mentioned in the analysis are from a quick brainstorm, and we should expect that at the time the DOMS Client is mature enough to support its four clients, there would have been implemented an estimated 10-40% more methods in addition to the ones mentioned. ## Add a high level task (goals / sub-goals) description here, sufficiently detailed to provide a background for creation of action descriptions. ## Any available (technical) details goes into the below documentation pages. == Sub tasks == <> == Documentation == ## The documentation section links to the documentation relevant to this task and its sub-tasks (if any). ## ## The below links will automatically be expanded to page names like "Tasks/X/Y/AnalysisDocument" in your created page. ## This should be a proper default. ## ## DO NOT comment out these links. * [[Tasks/30/AnalysisDocument|Analysis Document]] * [[Tasks/30/DesignDocument|Design Document]] * [[Tasks/30/SystemMaintenanceDocument|System Set-up and Maintenance Document]] == Progress history == <> ## Add information about about the current state of the task here. That is, information about what has been completed so far and ## what outstanding issues are left. Example: ## ##=== 2007-09-13 === ##Finished the design documentation. A review is needed before this task is completed. ## ##=== 2007-08-25 === ##Completed requirement specification. We are now ready for writing the design document.