[Bitrepository-devel] GetChecksums operationen

[Kim Teglgaard Christensen]

For min skyld må du gerne ryde op i GetChecksumsProgressResponse, men
det kan være at en af arkitekterne bag har haft en ide med hvorfor de
tre felter er med?

'FileIDs' og 'ResultAddress' er som sådan ikke fjernet fra
GetChecksumsFinalResponse. 'ResultAddress' er som en af felterne under
'ResultingChecksums' og 'FileIDs' som ChecksumDataItems ;) 

Fil / data formatet på uploadede resultater snakkede Mikis og jeg om for
lidt siden, og vi undrede os lidt over at der ikke var nogen
specifikation på det. 

Jeg havde faktisk ikke gjort mig de store tanker om formatet, men ideen
om at lave en rå tekst fil med tab sepererede colonner havde slået mig,
men det er nok ikke just noget som er særlig java venligt. 

Må jeg forslå at vi bruger JSON? (http://www.json.org/)
Vi bruger det allerede her til nogle outputs fra vores backend, og det
er forholdsvist nemt at gå til. 

Mvh Kim

On Wed, 2011-10-19 at 16:05 +0000, Jonas Lindberg Frellesen wrote:
> Hej alle,
> 
>  
> 
> I forbindelse med implementering af GetChecksums operationen på
> ReferencePillar’en har jeg fundet følgende, der undrer mig:
> 
>  
> 
> I GetChecksumsProgressResponse kan man give ’FileIDs’, ’ResultAddress’
> og ’FileChecksumSpec’ med. Men der er ikke nogen af dem, som virker
> relevante i den besked. Den, der har sendt beskeden, ved vel godt
> hvilke filer der er blevet efterspurgt, hvilket adresse der skal
> oploades til, og hvilken checksum algoritme der skal bruges til
> beregningerne. Behøver man bekræfte det?
> 
>  
> 
> Både ’FileIDs’ og ’ResultAddress’ er fjernet fra
> GetChecksumsFinalResponse, men den indeholder stadig
> ’FileChecksumSpec’. 
> 
>  
> 
>  
> 
> Når man skal uploade resultaterne af en checksumsberegning til en URL,
> hvilket format skal man så bruge?
> 
>  
> 
> Det vil være logisk at bruge samme struktur som i beskederne (altså
> ResultingChecksums eller en liste af ChecksumDataForChecksumSpecTYPE),
> men det vil Jaxb ikke parse (den mangler et ’root’ element).
> 
> Det giver heller ikke mening at printe selve objekterne ud, da de
> indeholder en masse ’objekt’ data. Det ser f.eks. ud på følgende måde:
> 
> org.bitrepository.bitrepositoryelements.ChecksumDataForChecksumSpecTYPE at 18bbf55[fileID=default-test-file.txt1319038823757, checksumValue=940a51b250e7aa82d8e8ea31217ff267, calculationTimestamp=2011-10-19T17:40:26.817+02:00]
> 
>  
> 
> Hvilket format skal vi så bruge til at uploade resultaterne med?
> 
>  
> 
>  
> 
> Og til sidst, så vil jeg bare sige, at ReferencePillar’en nu kan
> fuldføre en komplet samtale med GetChecksumsClient’en.J
> 
> Men den skal nok rettes lidt til, når de ovenstående spørgsmål bliver
> besvaret.
> 
>  
> 
>  
> 
> Med venlig hilsen
> 
> Jonas
> 
>  
> 
> http://support.kb.dk/images/kb_logo.jpg
> 
> 
> Det Kongelige Bibliotek
> Nationalbibliotek og Københavns
> Universitetsbibliotek 
> 
> 
> Jonas Lindberg Frellesen
> Softwareudvikler | Software
> Developer
> 
> Det Kongelige Bibliotek | The Royal
> Library
> Afdelingen for Digital Bevaring |
> Digital Preservation
> P.O. Box 2149 | DK-1016 København K
> tel +45 3347 4691 | Fax +45 3393
> 2218 | jolf at kb.dk | www.kb.dk
> 
> Besøgsadresse | Visiting address |
> Søren Kierkegaards Plads 1
> Leveringsadresse | Delivery address
> | Christians Brygge 8 | 1219
> København K
> 
> EAN 5798 000 79 52 97 | Bank 0216
> 4069032583 | CVR 28 98 88 42
> IBAN DK2002164069032583 | Swiftcode
> DABADKKK
> 
> 
> 
>  
> 
>  
> 
>