[RFC] strawman explict object-tracking API

[Robert Collins]

On Tue, 2007-04-17 at 16:11 +1000, Martin Pool wrote:
> 
> Basically like the idea but I have some thoughts:

Good. I think we're into detail rather than concept then. One thing we
could do as a first step is to shuffle the existing code, with no new
features around until the SFTP cache is gone and every code path
accessing multiple urls is providing a transport cache back to the
transport layer. This is afterall the main thrust. It would not offer
reuse of repositories and branches, but it would be an improvement; and
would shed light on how far this first change has to propogate - that
would be good data to have when considering if we want a broader session
like object.

> Why a dictionary rather than just a list?  What would the key be?

object:owners but it wasn't really thought out in detail.

> I'm not so sure this thing wants to support the whole dictionary
> protocol and should be a userdict.
> 
> It seems to me it would be a better fit to actually the 'recycler'
> object and say "please get me a transport", and then it knows how to
> ask each of the objects that are available for reuse.

Theres a difference between transports and repositories here. a
transport can be adapted to give a new transport, where as a repository
we just reuse. I'm not sure if this matters or not, but I am leaning
towards 'it does'.

> Possibly this should be split out into a more general Session object
> that holds all this per-context state.  get_transport and similar
> top-level factories would then go off that object.  That may be an
> over generalization.  I'm not sure you would want the lifecycle of
> reuse of all these objects to be the same.

-1 on this for now - premature generalisation I think. I'm pretty sure
there will be different lifetimes, but the sheer multitude of code paths
that open things may drive use to having a single common object anyway.

> I'm not so keen on "OpenBranch" because "open" is ambiguous as an
> adjective or verb, and it seems to describe the state of the branch
> itself, and because these things may be useful even when the actual
> connection is no longer open.

I chose Open because we get Branches via 'open' methods, but I'm happy
to search for a better name. I don't like Reusable because it doesn't
describe enough about how we are going to be using these things. 

> To implement these generically we seem to need two interfaces,
> something like
> 
> Reusable:
> 
>   reuse(args, kwargs):
>      Try to reuse this object instead of constructing a new object
> with the given constructor arguments.  This can return self, or a new
> object based on self, or None if it's not possible.

I'm not sure we need this. For Transports cloning is an existing
interface. For repositories and branches just being at the url we want
to open a branch at (nb - *at*, not at-or-above) is sufficient. Having
an interface on the object is useful if we want to delegate behaviour to
the object. Possibly you are suggesting that we can have a completely
abstract interface to achieve reuse by having the test for 'can this be
reused in this situation' delegated to the object. We probably can, but
I don't like having to use *args, **kwargs - they are pernicious
constructs in general, so at that moment I'd rather have multiple
'Reuser' objects with non-keyward based methods to get reuse, than one
'Reuser' class whose reuse take kwards.

> ReusePool:
> 
>   create_or_reuse(args, kwargs):
>      Used in place of constructing a new object with the given
> parameters.
>      Either return an appropriate reused object, or construct and
> remember a new one.
> 
>   register(obj):
>      Remember an object as a possible source of reuse.
> 
>   deregister(obj):
>      ...
> 
> Maybe there's an existing pattern name for this?

I don't really like the ReusePool approach at this point. I considered
something like it when putting my proposal forward. What I dont like
about it is that it we'll need a bunch of these - one for BzrDir's, one
for Repositories, one for Branches etc - I think that pushing this into
the Branch, Repository, BzrDir respective open methods is cleaner. But
perhaps a prototype will show this wrong?

> This could perhaps be used by transports to cache network connections,
> and maybe also to remember credentials (eg for http).

Well, most transports already have a 'Transport' vs 'Connection'
internal abstraction already - get_transport doing what I proposed will
give the effect of caching network credentials cleanly within a single
'cache'. (Its not a 'cache' because its not transient data backed
elsewhere).

-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/20070417/6e20d8d1/attachment-0001.pgp