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:

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

Problems with the test bitstorage

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.