view contrib/plan9/README @ 40132:e67522413ca8

wireprotov2: define and use stream encoders

Now that we have basic support for defining stream encoding, it is
time to start doing something with it.

We define various classes implementing stream encoders/decoders for
the defined encoding profiles. This is relatively straightforward.

We teach the inputstream and outputstream classes how to encode,
decode, and flush data.

We then teach the clientreactor how to filter received data through
the inputstream decoder.

One of the features of the framing format is that streams can span
requests. This is a differentiating feature from say HTTP/2, which
associates streams with requests. By allowing streams to span requests,
we can reuse compression context data across requests/responses. But
in order to do this, we need a mechanism to "flush" the encoder at
logical boundaries so that receivers receive all data where it is
expected. And a "flush" event is distinct from a "finish" event from
the perspective of certain compressors because a "flush" will retain
compression context state whereas a "finish" operation will not. This
is why encoders have both a flush() and a finish() and each uses
specific flushing semantics on the underlying compressor.

The added tests verify various behavior of decoders via clientreactor.
These tests do test some compression behavior via use of outputstream.
But for all intents and purposes, server reactor support for encoding
is not yet implemented.

Differential Revision: https://phab.mercurial-scm.org/D4921

Mercurial for Plan 9 from Bell Labs
===================================

This directory contains support for Mercurial on Plan 9 from Bell Labs
platforms. It is assumed that the version of Python running on these
systems supports the ANSI/POSIX Environment (APE). At the time of this
writing, the bichued/python port is the most commonly installed version
of Python on these platforms. If a native port of Python is ever made,
some minor modification will need to be made to support some of the more
esoteric requirements of the platform rather than those currently made
(cf. posix.py).

By default, installations will have the factotum extension enabled; this
extension permits factotum(4) to act as an authentication agent for
HTTP repositories. Additionally, an extdiff command named 9diff is
enabled which generates diff(1) compatible output suitable for use with
the plumber(4).

Commit messages are plumbed using E if no editor is defined; users must
update the plumbed file to continue, otherwise the hg process must be
interrupted.

Some work remains with regard to documentation. Section 5 manual page
references for hgignore and hgrc need to be re-numbered to section 6 (file
formats) and a new man page writer should be written to support the
Plan 9 man macro set. Until these issues can be resolved, manual pages
are elided from the installation.

Basic install:

  % mk install      # do a system-wide install
  % hg debuginstall # sanity-check setup
  % hg              # see help

A proto(2) file is included in this directory as an example of how a
binary distribution could be packaged, ostensibly with contrib(1).

See https://mercurial-scm.org/ for detailed installation
instructions, platform-specific notes, and Mercurial user information.