Serializer_v5._pack_revision and _unpack_revision to become public?

[David Allouche]

On Tue, 2006-01-17 at 11:30 +1100, Robert Collins wrote:
> On Tue, 2006-01-17 at 01:06 +0100, David Allouche wrote:
> > <collection>
> >   <revision yadda yadda>blah blah blah</revision>
> >   <dummy revision_id="jabberwock"/>
> >   ...
> > </collection>
> > 
> > <revision> and <dummy> items are unordered.
> 
> so whats the extension data ? the dummy entries ?

The <dummy> elements, and the root <collection> element that glues it
all into something ElementTree can parse.

> > The requirements for the cache are the following:
> > 
> >       * Fast to read and write. cElementTree is fast at reading, but
> >         still seems to use a Python implementation for writing. I would
> >         like no slower reading and faster writing.
> >       * Safe to use with data that is no more trusted than any branch
> >         data than you can find anywhere on the internet.
> >       * Allows embedding of blackbox bzr data in a foreign data format.
> >         I do not care how revisions are stored, but I want to mix them
> >         with my own data.
> 
> ah, so the thing here is not storing extension data in bzr storage, its
> serialising bzr object in your own storage format.

Yup.

> 
> I'm inclined to say 'bzr serialisation is library internals, if you are
> storing bzr objects, just use pickle or $any python serialisation form'.

The thing is that I do not know of any fast, transparent and secure
Python serialization tool in the standard library. Pickle is insecure,
marshall is not transparent (cannot serialize object, and anyway just
meant to be used for .pyc files).

What you are saying amounts to "do your own serialization". bzrk would
work if I just duplicated the _pack_revision and _unpack_revision, that
would violate Do No Repeat Yourself.

That would cause problems I do not have at the moment. For example, bzrk
does not know about revision properties, so if I wrote my own
serializer, it would not handle them. But then, when I modify the GUI to
display revision properties, I would have to also modify the serializer
to write and read them. Starting to smell like leaky abstraction,
doesn't it?

On the other hand, I would be happy to update bzrk to cope with (slowly)
evolving requirements of the serialization API, as long as it preserves
transparence, performance and security. 
-- 
                                                            -- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060117/49c7aede/attachment.pgp