[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