[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svndiff and XML

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-10-11 04:59:23 CEST

On Tue, Oct 10, 2000 at 10:23:03PM -0400, Greg Hudson wrote:
> >>... the byte 0 and high-bit-on bytes ...
>
> > Yup. Can't put those in. You also cannot include "<", ">", "&", and
> > sometimes the single/double quote characters.
>
> > This has been a known problem, and embedding this kind of text
> > within XML means that you must quote the stuff. Yes, it is
> > expensive.
>
> This comment seems to miss the point (although the rest of the
> messages suggests you may have gotten the point; I'm not sure). You
> can transport data including <>&'" through XML by quoting it; you
> simply can't transport data including zero bytes; "&#0;" is not
> well-formed.
>
> Thus the need to superencode the data.

Yah... I meant that we always knew that *some* kind of mass encoding would
need to happen. Since we're also sending binary data... well, ickier. :-)

So yes, I got the point. :-) ... just noting that even without the binary
data we were going to have issues.

XML brings us many benefits, but embedding raw binary is not exactly
straight-forward in XML :-(

> > Strip down the file that I just sent to what is needed.
>
> That implementation assumes the data to be encoded or decoded is all
> present at once, which is not the case for what we're doing. So, I
> could borrow a few lines of code to do the easy part, but I still have
> to deal with all the irritating edge cases.

Ah. Okee.

Note that you could use XML to define chunks of encoding. As each block
arrives at your encode() function, you could output:

<chunk>
  lsjflsjflsjfljaslfsf
</chunk>

Rather than worrying about buffering "pending" bits for the arrival of the
next chunk of data.

It might make it a bit easier to jumpstart your code.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:10 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.