Serializer_v5._pack_revision and _unpack_revision to become public?

[Robert Collins]

On Tue, 2006-01-17 at 12:52 +0100, David Allouche wrote:
>  
> > 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).

bzrlib is about writing a VCS, not a 'fast transparent and secure python
serialization tool'. What serialization logic we have is for the support
of bzrlib - and *if* appropriate we can expose that as supported
symbols. But I'm not at all convinced that this is an appropriate api to
expose at this point.

> 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.

Indeed. But bzrk is in a separate project - if we expose pack and unpack
revision, we are providing XML serialisation apis. Which is ok if we
wish to do that; I dont see why we would want to offer that *as an
embedding of bzr data into $foo*.

> 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?

bzr has an api for accessing revisions - branch.get_revision. If there
are issues with that API, lets work on them. Conversely, if we are going
to add other apis for accessing and storing revisions, we should have a
reason to do so. 

With respect to 'leaky abstractions' - exposing the internals (currently
xml) of a serialisation format is very leaky. pickle and other python
serialisers can use introspection, so theres no need to specifically
handle revision properties. As for the GUI - if you wish to support a
feature, yes you do need to write code. Its fairly common in GUI
environments to have a parallel hierarchy between content and
presentation objects. 

> 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. 

Well, if you were using the bzr serialization API, I'd completely agree.
As it happens you are using an implementation detail that even within
the library is not considered stable or for general use.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- 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/20060118/cac849be/attachment.pgp