## Action
= Action Integrate Bitstorage with Ingester =

Currently, the ingest module only contains stubs for the integration with Bitstorage. We have met with Drift, to
determine what they can deliver, and when.
The results of this can be seen in:
 * [[Minutes/2007-12-20| Referat 2007-12-20]]
 * [[Minutes/2008-01-10| Referat 2008-01-10]]
 * [[Minutes/2008-01-28| Referat 2008-01-28]]
 * BitstorageAgreement

The most important bit in these are that while we will get a bitstorage, the individual upload of files will only be in the test system. At first,
Drift will handle upload into the production system.

This leads to the following subactions
 * (0.5 md x 2) DONE(0.5md) Followup on the meeting with Drift (10. of january)
 * (2-3 md) DONE(2md) Alter the ingest module to use the test-bitstorage system
 * (0.5 md) DONE(0md) Alter the preingester to construct proper links to the files in the production Bitstorage. 
 * (1 md, quick but meeting) DONE(0.5md) Decide which charset to use for the filenames. The filename is just an URL encoded byte array. We can use whatever, as long as it match the byte array. We use UTF8 in filenames, and will have some ugly links as a result
 * (0.5 md) DONE(0.5md) Meet with IT-maintenance at the end of january 2008 to talk about production BitStorage.

ABR: 3.5 md

## Detailed description of wanted output from the work to be carried out.
## E.g. Implement a utility class for writing data to a disk. The data must be base64 encoded before being written.

## Targeted WBS Tasks and Assigned Developers can be found on the iteration page for this action.

== Problems with the test bitstorage ==

 1. Use can approve a file, without specifying the md5 sum. This allows for injection attacks, where two users upload, and the wrong file is approved. Some kind of locking would be nice here. It is unclear whether this locking shold be implemented at BitStorage-level or DOMS-interaction level.