"Russell Hind" <rh_gmane@mac.com> wrote in message news:cl66ju$ftg$2@sea.gmane.org...
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 for a 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 applications 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?
Thanks
Russell
_______________________________________________ Unsubscribe & other changes: