[RFC] Transport hints
John Arbash Meinel
john at arbash-meinel.com
Mon Jul 24 14:16:31 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vincent LADEUIL wrote:
...
> 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.
Not really. We need to switch back and forth multiple times within a
single transport, so it has to be per request.
As specific examples:
redirect: We don't want to redirect when requesting .bzr/branch-format
the first time, because that is the first connect to the branch, and
will tell us the branch has been moved.
Future requests should be redirected, so that we don't get spurious
errors later.
prefetch: We probably want 'prefetch' on for any 'get' request, but we
want it off for any 'readv()' request. (readv() does a get() and then
seek + read on the returned file).
We could implement this N different ways, but changing the API such that
every transport has to implement something they are going to ignore
seemed wrong. And especially since I'm adding 2 of them in a short
period of time.
>
> 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 ?
Most of them will ignore them, hence why I wanted to call them 'hints'.
>
> 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.
I'm fine with an options object instead of dict. The reason to not do it
transport by transport is that I want to be able to write code that
doesn't have to special case based on what transport it is connected to.
(Transport is supposed to *be* the abstraction).
>
> 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
I didn't see how Robert defined how he wanted to do it as a factory. I
saw an object, but I guess he was thinking to either change Transport to
have a new member, or creating a different factory function (like
get_transport).
Because you need to know what options to set before you make the
request, I don't see much use in having a Options factory, since only
known options can be set. So if the parameter isn't part of the
TransportGetOption api, I don't see how a generic client can set it.
But I suppose if someone implemented a custom transport, they might
implement custom options, and use introspection or something to figure
out what was available...
I'll think about the factory some more. But I'm fine with having a fixed
class, so that you have spelling safety.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFExMgvJdeBCYSNAAMRApHZAKC06Vx8/nI42vSrPpAijmbyQvMTJACgwq4R
w1wrz6St0HLczBwymDV+ocU=
=EUUE
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list