[RFC] strawman explict object-tracking API

[Robert Collins]

On Tue, 2007-04-17 at 09:52 -0400, Aaron Bentley wrote: 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> > We could put a list of registered objects into each domain - e.g. have
> > 'bzrlib.transport._open_transports', but I think this is pure ugly: Its
> > not discoverable to users of the api, its not good for threaded apps
> > like servers, it makes testing complex.
> 
> On the other hand, it may force clients to cart around a bunch of extra
> "cache" objects.

Indeed, thats the explicit tradeoff I'm suggesting: Rather than a static
location for any given 'cache' its rather a dynamic object.

> For the bzr client, I can't really imagine circumstances where I'd say
> "Open a branch, and don't reuse any existing objects, please".  In
> selftest, sure, but not in normal commands.

Sure. We do however require thread safety and isolation for 'bzr serve'.

> I think I like Ian's suggestion of a context object better, but more, I
> would like Branch.open_containing() to DTRT without me having to
> intervene.  I think wanting to avoid the cache is a lot less common than
> wanting the cache, and we should optimize the API for the our common use
> cases.

Well, Ian's suggestion is basically 'add an additional wrapper to hold
all these things'. Myself, I'm deeply skeptical of 'Context' objects
that dont have a strictly defined lifetime, and I got the impression
that Ian was largely talking about moving responsibility for obtaining
branches etc to a single place. I'd generally label this pattern a
Facade.

> I also worry about testing.  Detecting misuse of your suggested API will
> require careful testing.  Most commands are not tested by running them
> with the same branch repeated (e.g. "bzr merge .").  But if we don't
> make reuse the default, then we will probably get a lot of commands that
> don't reuse objects, even when they should.

I think you mean 'Finding commands that fail to reuse
branches/transports/repositories correctly is a problem'?

I think it cannot be automated without additional data about each
command. For instance, 'merge .' clearly should not do any operation
when its the same branch - reusing the same branch would be a bug in
this case. 'bzr pull URL' where the cwd branch is bound to URL should
also special case - it shouldn't end up doing
Branch(URL).pull(Branch(URL)) as thats also wasteful. 

When its the same repository however, with different branches - that
becomes a useful thing, because we can short circuit fetch/missing etc
operations. That can be done via InterRepository specialisation, or via
caching whats opened. I'm primarily interested in fixing transports at
this point, and seeing how far it spreads; we can convert that to a more
generic object if we choose to in the future IMO.

-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/20070418/f0159400/attachment.pgp