Mercurial > hg
view mercurial/peer.py @ 37558:8a73132214a3
httppeer: support protocol upgrade
With the new handshake defined and in place on the server, we can
now implement it on the client.
The HTTP handshake mechanism has been taught to add headers advertising
its support for the new capabilities response. Response handling
has been adjusted to allow CBOR responses through. And makepeer()
has been taught to instantiate a mutually supported peer.
The HTTPv2 peer class doesn't implement the full peer interface. So
HTTPv2 is not yet usable as a peer.
Like the server side, we support registering handlers for
different API services. This allows extensions to easily implement
API services and peers. A practical use case for this is to
provide a previous implementation of the experimental version 2
wire protocol to a future version of Mercurial. We know there will
be BC breaks after 4.6 ships. But someone could take the peer and
server code from 4.6, drop it in an extension, and allow its use
indefinitely.
Differential Revision: https://phab.mercurial-scm.org/D3243
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Tue, 10 Apr 2018 18:16:47 -0700 |
parents | 115efdd97088 |
children |
line wrap: on
line source
# peer.py - repository base classes for mercurial # # Copyright 2005, 2006 Matt Mackall <mpm@selenic.com> # Copyright 2006 Vadim Gelfer <vadim.gelfer@gmail.com> # # This software may be used and distributed according to the terms of the # GNU General Public License version 2 or any later version. from __future__ import absolute_import from . import ( error, pycompat, util, ) # abstract batching support class future(object): '''placeholder for a value to be set later''' def set(self, value): if util.safehasattr(self, 'value'): raise error.RepoError("future is already set") self.value = value class batcher(object): '''base class for batches of commands submittable in a single request All methods invoked on instances of this class are simply queued and return a a future for the result. Once you call submit(), all the queued calls are performed and the results set in their respective futures. ''' def __init__(self): self.calls = [] def __getattr__(self, name): def call(*args, **opts): resref = future() # Please don't invent non-ascii method names, or you will # give core hg a very sad time. self.calls.append((name.encode('ascii'), args, opts, resref,)) return resref return call def submit(self): raise NotImplementedError() class iterbatcher(batcher): def submit(self): raise NotImplementedError() def results(self): raise NotImplementedError() class localiterbatcher(iterbatcher): def __init__(self, local): super(iterbatcher, self).__init__() self.local = local def submit(self): # submit for a local iter batcher is a noop pass def results(self): for name, args, opts, resref in self.calls: resref.set(getattr(self.local, name)(*args, **opts)) yield resref.value def batchable(f): '''annotation for batchable methods Such methods must implement a coroutine as follows: @batchable def sample(self, one, two=None): # Build list of encoded arguments suitable for your wire protocol: encargs = [('one', encode(one),), ('two', encode(two),)] # Create future for injection of encoded result: encresref = future() # Return encoded arguments and future: yield encargs, encresref # Assuming the future to be filled with the result from the batched # request now. Decode it: yield decode(encresref.value) The decorator returns a function which wraps this coroutine as a plain method, but adds the original method as an attribute called "batchable", which is used by remotebatch to split the call into separate encoding and decoding phases. ''' def plain(*args, **opts): batchable = f(*args, **opts) encargsorres, encresref = next(batchable) if not encresref: return encargsorres # a local result in this case self = args[0] cmd = pycompat.bytesurl(f.__name__) # ensure cmd is ascii bytestr encresref.set(self._submitone(cmd, encargsorres)) return next(batchable) setattr(plain, 'batchable', f) return plain