chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joram Barrez <joram.bar...@gmail.com>
Subject Re: Objective-CMIS: base64 input streaming
Date Thu, 28 Feb 2013 09:53:29 GMT
Yes, it does make sense. And I do agree that a stream implementation is
better than the tmp file approach.

But te 'byte jiggling' makes me kinda nervous. There's plenty that can go
wrong once one decide to jiggle bytes ;-). So maybe add some more tests
with different types of files (very small, very large, etc...) to the test
suite so we have a bit more confidence in the implementation.


On Thu, Feb 28, 2013 at 10:35 AM, Peter Schmidt
<peter.schmidt@alfresco.com>wrote:

> Hi Joram
> indeed it took a bit of byte jiggling.
>
> The trick is to read an integer multiple of 3 from the non-encoded source
> input stream. That way you guarantee that the base64 encoder won't pad the
> encoded bytes with = at the end.
> The exception, of course, is when you reach the end of the source stream,
> where = padding is expected.
>
> The second trick is to write out as many bytes as are requested in the
> read:maxLength statement. This means, filling the buffer with XML and
> base64 encoded data - and storing the remainder in a tmp buffer until the
> next read.
>
> We also need to ensure that the base64 input stream returns "has bytes
> available" even if the source input stream is exhausted.
>
> I tested it in the XCode profiler, and the memory foot print seems to be
> comparable with what we had before.
>
> Hope that makes sense?
>
> Regards
> Peter
>
>
>
> On 28 February 2013 09:17, Joram Barrez <joram.barrez@gmail.com> wrote:
>
> > > when a read request is being sent to the new input stream class, the
> XML
> > > encapsulation and base64 encoding is done on the fly
> >
> > I remember I looked around for a streaming base64 implementation, but
> > couldn't find something ready to use in ios straight away.
> >
> > Are you using some library or are you keeping some characters in memory
> > until you have enough to do the encoding (like described eg in
> >
> >
> http://stackoverflow.com/questions/7920780/is-it-possible-to-base64-encode-a-file-in-chunks
> > )?
> >
> >
> >
> >
> > On Thu, Feb 28, 2013 at 10:03 AM, Peter Schmidt
> > <peter.schmidt@alfresco.com>wrote:
> >
> > > Hi all
> > > just a brief heads-up:
> > > I am going to submit a change in the way content is being uploaded from
> > the
> > > device to the server.
> > > How it works at present:
> > > * a temporary file is created containing the CMIS XML and base64
> encoded
> > > data.
> > > * a NSInputStream pointing to the tmp file is created
> > > * the HTTP request BodyStream property is being set to this tmp input
> > > stream
> > >
> > > The new code will do the following:
> > > * a new class CMISBase64InputStream is being provided, which inherits
> > from
> > > NSInputStream. It is being initialised with the original source input
> > > stream (raw data).
> > > * the HTTP request BodyStream property is being set to the
> > > CMISBase64InputStream object.
> > > * when a read request is being sent to the new input stream class, the
> > XML
> > > encapsulation and base64 encoding is done on the fly
> > >
> > > I tested it in both unit tests and a sample app, and it seems to work.
> > > Unless there are objections, I will submit the new code by end of play
> > > tomorrow, Fri 1 March
> > >
> > > --
> > > Kind regards
> > > Peter
> > >
> > > -----------
> > > *Peter Schmidt*
> > > *Alfresco Software Ltd.*
> > > *UK: 07748 185496*
> > > *Int.: 0044 7748 185496*
> > > *Skype: pweschmidt*
> > >
> >
>
>
>
> --
> Kind regards
> Peter
>
> -----------
> *Peter Schmidt*
> *Alfresco Software Ltd.*
> *UK: 07748 185496*
> *Int.: 0044 7748 185496*
> *Skype: pweschmidt*
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message