On Mon, Apr 02, 2001 at 12:32:32PM -0400, Greg Hudson wrote:
> > * Use some kind of checksum on the wire and in the DB. Given that whatever
> > is in source control is probably quite important, it would be a Good Thing
> > if we hashed/checksummed the data.
>
> For checksums on the wire: I am really hesitant to solve problems
> which (a) haven't been observed in the past (to my knowledge), and (b)
> are supposed to be solved by our transport layer. (I'm assuming here
> that CVS doesn't verify wire transfers with checksums; I could be
> wrong.) On the other hand, if it can be done purely using HTTP
> mechanisms, it wouldn't be the end of the world to do so.
I tend to agree here. But if it is cheap, using HTTP systems, then it
shouldn't be a problem for us [to satisfy the overly paranoid]. It isn't
going to help with TCP (which is already checksum'd), but will help with
problems in an end-to-end connection (i.e. a proxy that mucks it up). As you
point out, though, I'm not aware of any observances of this, nor of any
broken TCP stacks that don't checksum and verify the result.
[ hmm. actually, after I wrote that, I seem to recall there *was* a stack
somewhere that didn't check the checksums... ]
> For checksums in the DB: Larry makes a good argument that if you're
> storing very valuble data, you want checksums (or some other form of
> redundancy) in your permanent storage, and you want to periodically
> verify that none of the data is corrupt. On the other hand, we're not
> particularly targeting very expensive data; we're targeting the open
> source community, according to our web pages. So, I would say: we
> should ensure that our DB format is extensible enough to support
> adding per-revision fields, and we should treat this as a "some day"
> feature unless someone feels inspired to implement it right away.
Yup. And Jim just pointed out that we have something here already. I think
we should be able to do this with a pretty low impact.
> > * Diff formats.
>
> I feel like you're conflating the XML delta format with svndiff.
Um. I was trying to say that they *aren't* conflated. That we need to be
able to use arbitrary formats in there. And that SVNDIFF is useful in
certain cases (e.g. shipping diffs over the wire), but we need to have
multiple formats.
> We've always intended to use gnudiff format for passing stuff around,
> and it can be embedded in an XML delta just as easily as svndiff can.
> (Our code currently only deals with svndiffs, but that's a temporary
> state.)
All righty. I wasn't aware of our intent there. (thx!)
> I think you're correct, though, that the editor interface has to
> change in order to produce anything other than svndiffs. (It doesn't
> have to change to a pull model, but text delta windows aren't going to
> hack it.)
Yup. We could do it with something other than "pull", but pull solves other
problems for us. Specifically, it allows an editor implementor to use pull
*or* push, it allows Neon to pull data, it allows the editor to choose the
format that is "right" for it, etc.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:27 2006