From: Robert Ramey (ramey_at_[hidden])
Date: 2004-10-20 13:04:01
"Russell Hind" <rh_gmane_at_[hidden]> wrote in message
> Robert Ramey wrote:
> > When I wrote the code for encoding/decoding base64 I didn't include the
> > trailing "=" required by the standard defnition of base64. This was
> > couple of reasons:
> > a) My de-serialization code didn't require the existence of "=" padding
> > characters
> > b) I didn't anticipate that the base64 text would be used by
> > other than serialization
It would seem that you're using the xml archive for purporses other than for
serialization. Of course I don't see any problem with this (until one
decides to edit it and change its schema). But I am curious what use you've
found fot it. I originally did it only to satisfy boost nit-pickers as I
felt it was an inefficient way to implement serialization. I've since found
it useful for debugging archives. I seems to be compatile with xml viewers
so its useful for rendering archives in a visible way. So, after all I have
to concede that the nit-picker do have a point. I have a sneaking suspicion
that it will turn up in all kinds of unexpected places and I'm wonder what
those might be.
> > c) I was short of time and had lots of other things to do.
> > We'll take a look at this for 1.33.
> In that case, is there a way I can get a 'string' of base64 encoded data
> from the archive and write it as a string so I can handle this myself?
> I'm trying to generate data that can be passed by other systems but if
> it doesn't add this stuff in, then thats harder to do.
you have a couple of options:
a) Make your own derivation of xml_(i/o)archive which uses your own version
of write/read_binary. Advantage - wouldn't touch the current archive
classes. The manual describes how to do this.
b) Just fix the current code that does the read/write_binary text data.
You could roll this in to your own version of 1.32 and be on your way. This
is implemented as part of the dataflow iterators and I don't think this is
very difficult except that that understanding my dataflow iterator idea
would take some investment of effort that might not be worthwhile. There is
already a test for serialization of binary data so even that is done. The
reason I don't do it now is that it starts a whole chain reaction regarding
testing on all the platforms that boost supports and it is a very
inconvenient time to do this. Also no one raised the issue until now.
> I'm happy to call the encoding routine myself and append the data if you
> can give some pointers as to how I do this?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk