[RFC] Transport hints

Vincent LADEUIL v.ladeuil at alplog.fr
Mon Jul 24 09:55:39 BST 2006


>>>>> "Robert" == Robert Collins <robertc at robertcollins.net> writes:

    Robert> On Sun, 2006-07-23 at 07:41 -0500, John Arbash Meinel
    Robert> wrote:
    jam> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
    jam> 
    jam> I've been thinking about both sftp and http lately, and
    jam> how we want to make customized get requests.  For sftp,
    jam> we want to do a get() while disabling prefetch, and for
    jam> http, we want to do one while disabling automatic
    jam> following of redirects.
    jam> 
    jam> Ultimately, this means we need to parameterize
    jam> Transport.get() so that we can pass these flags. And I
    jam> realized, I don't really want to add a new public
    jam> parameter, which then all transports need to implement,
    jam> even if they just ignore it.

Agreed.

    jam>  I realized that a 'hints' parameter would satisfy this
    jam> nicely. By calling it 'hints', it makes it clear that it
    jam> isn't strictly required, just a hint as to what should
    jam> be done.

+1 on the hint concept.

    jam> 
    jam> 
    jam> I've thought about doing it two ways:
    jam> 
    jam> def get(relpath, **hints):
    jam> 
    jam> versus
    jam> 
    jam> def get(relpath, hints={}):
    jam> 
    jam> Then all transports just need to add one more field,
    jam> which they treat as a dict that they can extract hints
    jam> from.
    jam> 
    jam> My question is, which way would be better? I prefer the
    jam> syntax of the former, mostly because it is shorter, and
    jam> easier to type:
    jam> 
    jam> a_transport.get(relpath, prefetch=False)
    jam> 
    jam> versus
    jam> 
    jam> a_transport.get(relpath, hints={'prefetch':False})
    jam> 
    jam> However, I kind of like that the later is more obvious
    jam> that we are giving a hint.
    jam> 
    jam> Anyone have a particular preference?

I prefer the later.

But I find it surprising to have it on the 'get' level instead of
the transport level. The option  may not be active for every get,
but I can't see how the  user can specify, for a given transport,
which path should take an option into account.

I  feel that parts  of the  paths should  take some  options into
account and it may be easier  to tell the transport to switch the
option on  or off for the  next 'get's. If the  options should be
active for  a whole "session"  then specifying them  at transport
creation will suffice.

    Robert> I dont get what this buys us over def
    Robert> get_no_prefetch(relpath) - define once, at the top or
    Robert> def get(relpath, prefetch=False): - which is clear,
    Robert> and language checked for typos.  or def get(relpath,
    Robert> options=None): ...  class GetOptions(object):

    Robert>     def __init__(self, prefetch=False,
    Robert> no_redirect=False): self.prefetch=prefetch
    Robert> self.no_redirect=no_redirect

    Robert> One could make GetOptions be factoried out from the
    Robert> transport - probably a good idea.

    Robert> our *interface* is what clients use, and that means a
    Robert> client may send prefetch=False, or redirect=False, to
    Robert> any transport, so they should all handle them.

If options are  related to one transport, others  should not even
be made aware of it, no ?

    Robert> Using an Options object is preferrable to a dict,
    Robert> because typos are checked rather than silently
    Robert> ignored. Also it means that all the known options are
    Robert> documented.

But that should be done transport by transport.

    Robert> Alloing Options to be made by a transport factory
    Robert> means new transports can extend the base Options we
    Robert> have made.

Agreed on  that, especially that it  put the options  back to the
transport level instead of the get one.

          Vincent




More information about the bazaar mailing list