From: Jennifer C. <jen...@at...> - 2009-09-21 17:56:07
|
Hi Tim, Thank you for confirming that. And thanks again for all your hard work to move NG4J to current libraries! Hearing nothing else yet I went ahead and committed the proposed change to no longer chunk digests. (If there's a reason to chunk digests then we can re-visit this and make further modifications before the next release - just let us know.) Jennifer -----Original Message----- From: Tim Pizey [mailto:tim...@ou...] Sent: Friday, September 18, 2009 4:03 PM To: ng4...@li... Subject: Re: [namedgraphs] Base64 encoding Hi Jennifer, The change was, indeed, made on a best guess basis, only motivated by removing warnings from the build, so please do as you see fit. yours Tim On Thursday 17 September 2009 20:50:09 Jennifer Cormier wrote: > Hi everyone, > > The Base64 encoding is working slightly different since the change > away from the sun libraries. (Note: I have no issues with the change, > and thank Tim for making it! We needed to move away from those libs.) > > If you run the SWPExample (in src/de.fuberlin.wiwiss.ng4j.examples) > and compare the functionality from the prior release, it can be seen > that the sun libraries didn't chunk the data when encoding. (i.e. no > carriage return is added after 76 characters.) > > The new code (e.g. in SWPSignatureUtilities.calculateDigest) is using > Base64.encodeBase64Chunked so it does insert the carriage return. > > >From what I've read, it's actually standard to include the carriage > return. > > HOWEVER I'm not sure we want to do that for the digest in NG4J. The > digest is then added to the warrantGraph as a literal (as the object > in an RDF statement about the digest). Perhaps that's legal, but it > does look odd when the RDF is written in whatever format. > > I'm assuming that change was made unintentionally and we could go back > to the chunk-less style? i.e. change to use Base64.encodeBase64 in > all places? > > Jennifer > > Jennifer P. Cormier > Sr. Computer Scientist > ATC-NY > www.atc-nycorp.com |