##// END OF EJS Templates
wireproto: support /api/* URL space for exposing APIs...
wireproto: support /api/* URL space for exposing APIs I will soon be introducing a new version of the HTTP wire protocol. One of the things I want to change with it is the URL routing. I want to rely on URL paths to define endpoints rather than the "cmd" query string argument. That should be pretty straightforward. I was thinking about what URL space to reserve for the new protocol. We /could/ put everything at a top-level path. e.g. /wireproto/* or /http-v2-wireproto/*. However, these constrain us a bit because they assume there will only be 1 API: version 2 of the HTTP wire protocol. I think there is room to grow multiple APIs. For example, there may someday be a proper JSON API to query or even manipulate the repository. And I don't think we should have to create a new top-level URL space for each API nor should we attempt to shoehorn each future API into the same shared URL space: that would just be too chaotic. This commits reserves the /api/* URL space for all our future API needs. Essentially, all requests to /api/* get routed to a new WSGI handler. By default, it 404's the entire URL space unless the "api server" feature is enabled. When enabled, requests to "/api" list available APIs. URLs of the form /api/<name>/* are reserved for a particular named API. Behavior within each API is left up to that API. So, we can grow new APIs easily without worrying about URL space conflicts. APIs can be registered by adding entries to a global dict. This allows extensions to provide their own APIs should they choose to do so. This is probably a premature feature. But IMO the code is easier to read if we're not dealing with API-specific behavior like config option querying inline. To prove it works, we implement a very basic API for version 2 of the HTTP wire protocol. It does nothing of value except facilitate testing of the /api/* URL space. We currently emit plain text responses for all /api/* endpoints. There's definitely room to look at Accept and other request headers to vary the response format. But we have to start somewhere. Differential Revision: https://phab.mercurial-scm.org/D2834

File last commit:

r34952:fb7f58da stable
r37064:1cfef569 default
Show More
config.txt
108 lines | 3.1 KiB | text/plain | TextLexer
All config options used within Mercurial should be registered.
Config Option in Core
=====================
Config options used by Mercurial core are registered in the
``mercurial.configitems`` module.
Simple entry
------------
A registration entry typically looks like::
coreconfigitem('section', 'option',
default=MyDefaultValue,
)
Once registered, Mercurial will know that ``section.option`` is a legitimate
config option and that ``MyDefaultValue`` should be used if no other values are
defined in configuration files.
Complex default value
---------------------
If the default provided is a callable, it is called to retrieve the default
value when accessing the config option. This is useful for default values that
are mutable like the empty list::
coreconfigitem('pager', 'ignore',
default=list,
)
In addition, there are cases where the default is not fixed, but computed from
other properties. In this case, use the ``dynamicdefault`` object as the value
for the ``default`` parameter. A default value is then explicitly required when
reading the option::
# registration
coreconfigitem('web', 'name',
default=dynamicdefault,
)
# usage
ui.config('web', 'name', dirname)
Free form options
-----------------
Some config sections use free form options (e.g. ``paths``). You can register
them using the ``generic`` parameters::
coreconfigitem('paths', '.*',
default=None,
generic=True,
)
When ``generic=True`` is set, the option name is matched as a regular expression
(rooted to string start). It can be used to select specific sub parameters::
coreconfigitem('merge-tools', br'.*\.args$',
default="$local $base $other",
generic=True,
priority=-1,
)
The ``priority`` parameter controls the order used to match the generic pattern
(lower first).
Config Option in Extensions
===========================
General case
------------
Extensions should register config items through the ``registrar`` API (also used
for commands and others)::
configtable = {}
configitem = registrar.configitem(configtable)
configitem('blackbox', 'dirty',
default=False,
)
The ``dynamicdefault`` object is then available as
``configitem.dynamicdefault``.
Supporting older versions
-------------------------
The registrar was introduced in Mercurial 4.3, and the ``generic`` parameter was
introduced in 4.4. Starting with Mercurial 4.4, all core options were registered
and developer warnings are emitted when accessing unregistered option.
Extensions supporting versions older than Mercurial 4.3 cannot rely on the
default value being registered. The simplest way to register an option while
still supporting an older version is to use ``dynamicdefault`` for options
requiring a default value. The existing code passing an explicit default can
then stay in use until compatibility with Mercurial 4.2 is dropped.
As reminder, here are the default values for each config type:
- config: None
- configbool: False
- configbytes: 0
- configdate: None
- configint: None
- configlist: []
- configpath: None