Difference between revisions of "Digilib"
m (link to escidoc solution overview page modified and formatting changed) |
m (→Current Status) |
||
| Line 5: | Line 5: | ||
==Frontend== | ==Frontend== | ||
The user interface is to integrate in the application (PubMan/Faces). I haven't tested this part. The current functionality is browser based and so I expecting minimal changes. | The user interface is to integrate in the application (PubMan/Faces). I haven't tested this part. The current functionality is browser based and so I expecting minimal changes. | ||
==Backend== | ==Backend== | ||
Revision as of 15:54, 23 September 2007
Digilib will probably be used for image handling within the eSciDoc infrastructure and some of the envisioned solutions. In general, Digilib can be seen as a combination of server-based business logic (image manipulation) and browser-based UI components. The idea is to integrate the server-based part of the software as intermediate service within the eSciDoc infrastructure.
Current Status[edit]
Frontend[edit]
The user interface is to integrate in the application (PubMan/Faces). I haven't tested this part. The current functionality is browser based and so I expecting minimal changes.
Backend[edit]
Digilib's integration in the eSciDoc architecture could be realized as Fedora Disseminator. Disseminators are Webservices with access to a HTTP stream instead of Digilib's direct file access. Digilib is to alter to operate with HTTP streams.
The direct file access is, with the used Java Advanced Imaging API (JAI), easy to replace against a network access method. These methods produce a BufferedImage, which may lead to higher memory requirements. It is to probe if the buffered images method influences the rendering speed dramatically.
Currently operate Digilib's image transformations with random files access. This is, without special functions or libraries, not directly given via HTTP streams. If random file access on HTTP stream is a requirement for fast image transformation than could the unified IO library (https://uio.dev.java.net/) bring speed up. For non-complex image transformations, like scaling and clipping on standard sized images (5 MiB), is this not necessary.
Storage of Parameter and Annotation[edit]
Digilib parameters are part of the URL. The consequence is that these parameter are still part of the framework based URL (e.g. http://escidoc/ir/item/<itemId>/content/<contentId>?param1=value1¶m2=value2).
The annotations and transformation parameter are handled not as eSciDoc dataset. Should digilib parameters be stored in the properties or metadata of binary content? What would be the best way to hold different annotations for one image?