[MERGE][RFC] Add doc/developers/network-protocol.txt to describe the HPSS protocol; streaming body extension to HPSS protocol.
Andrew Bennetts
andrew at canonical.com
Mon Sep 3 18:11:34 BST 2007
Martin Pool wrote:
> Martin Pool has voted resubmit.
> Status is now: Resubmit
> Comment:
> +
> +:Date: 2007-09-03
> +
>
> (comment) I do wonder if anyone will update this, or whether having an
> overall last-modified-date is very useful compared to saying what
> version of Bazaar uses each protocol version.
I wonder too. I borrowed this convention from an existing document. It can be
nice to know how recent a document is.
[...]
> +
> + Possibly this should just be RemoteBzrDir, RemoteTransport,
> + ...
>
> Is this in fact now just RemoteBzrDir etc?
Yeah. I've simplified this to say “This is RemoteBzrDir, RemoteRepository,
etc.”.
> Would it be good to show "rest of bzrlib" sitting under the HANDLER and
> above the CLIENT respectively?
Hmm, “domain objects” implies that already I think. I tried adding in “rest of
bzrlib” into the pseudo-diagram but it didn't feel like it helped make it any
clearer.
> + RESPONSE_V2 := "bzr request 2" NEWLINE MESSAGE_V2
>
> really?
Ahem. No. s/request/response/
> +Software versions
> +-----------------
> +
> +Version 1 of the protocol was introduced in Bazaar 0.11.
> +
> +Version 2 was introduced in Bazaar 0.16.
> +
>
> You might put these in the corresponding headings rather than down here.
> If I understand correctly, Bazaar 0.90 sends the version identifier but
> can't handle the chunked encoding? That should be documented.
I've moved it into those sections.
Bazaar 0.90 can't handle the chunked encoding... but then it will never send
requests that will generate chunked responses.
> In other words they'll want to rewrite
> +incoming paths to be under that level (and prevent escaping using ../
> +tricks.)
>
> Should we say something about ChrootTransport etc?
Good idea. Done.
> +URLs that include ~ should probably be passed across to the server
> +verbatim and the server can expand them. This will proably not be
> +meaningful when limited to a directory?
>
> You could link the bug for this.
Done.
> +Requests
> +========
> +
> +The available request methods are registered in `bzrlib.smart.request`.
>
> I'd like if we could document the rpcs in this file, or one linked from
> here, as they're important compatibility points. For now could you at
> least invite people to document them below?
Done.
-Andrew.
-------------- next part --------------
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: andrew.bennetts at canonical.com-20070903170956-\
# ymungucmrn9yuk82
# target_branch: http://bazaar-vcs.org/bzr/bzr.dev
# testament_sha1: 04e56b2deafb6b3f1341303fb1a86c058a3446f8
# timestamp: 2007-09-04 03:10:16 +1000
# source_branch: http://people.ubuntu.com/~andrew/bzr/hpss-protocol-\
# docs
# base_revision_id: pqm at pqm.ubuntu.com-20070902233606-wb062d366w5c83uc
#
# Begin patch
=== added file 'doc/developers/network-protocol.txt'
--- doc/developers/network-protocol.txt 1970-01-01 00:00:00 +0000
+++ doc/developers/network-protocol.txt 2007-09-03 17:09:56 +0000
@@ -0,0 +1,235 @@
+================
+Network Protocol
+================
+
+:Date: 2007-09-03
+
+
+.. contents::
+
+
+Overview
+========
+
+The smart protocol provides a way to send a requests and corresponding
+responses to communicate with a remote bzr process.
+
+Layering
+========
+
+Medium
+------
+
+At the bottom level there is either a socket, pipes, or an HTTP
+request/response. We call this layer the *medium*. It is responsible for
+carrying bytes between a client and server. For sockets, we have the idea
+that you have multiple requests and get a read error because the other
+side did shutdown. For pipes we have read pipe which will have a zero
+read which marks end-of-file. For HTTP server environment there is no
+end-of-stream because each request coming into the server is independent.
+
+So we need a wrapper around pipes and sockets to seperate out requests
+from substrate and this will give us a single model which is consistent
+for HTTP, sockets and pipes.
+
+Protocol
+--------
+
+On top of the medium is the *protocol*. This is the layer that
+deserialises bytes into the structured data that requests and responses
+consist of.
+
+Request/Response processing
+---------------------------
+
+On top of the protocol is the logic for processing requests (on the
+server) or responses (on the client).
+
+Server-side
+-----------
+
+Sketch::
+
+ MEDIUM (factory for protocol, reads bytes & pushes to protocol,
+ uses protocol to detect end-of-request, sends written
+ bytes to client) e.g. socket, pipe, HTTP request handler.
+ ^
+ | bytes.
+ v
+
+ PROTOCOL(serialization, deserialization) accepts bytes for one
+ request, decodes according to internal state, pushes
+ structured data to handler. accepts structured data from
+ handler and encodes and writes to the medium. factory for
+ handler.
+ ^
+ | structured data
+ v
+
+ HANDLER (domain logic) accepts structured data, operates state
+ machine until the request can be satisfied,
+ sends structured data to the protocol.
+
+Request handlers are registered in the `bzrlib.smart.request` module.
+
+
+Client-side
+-----------
+
+Sketch::
+
+ CLIENT domain logic, accepts domain requests, generated structured
+ data, reads structured data from responses and turns into
+ domain data. Sends structured data to the protocol.
+ Operates state machines until the request can be delivered
+ (e.g. reading from a bundle generated in bzrlib to deliver a
+ complete request).
+
+ This is RemoteBzrDir, RemoteRepository, etc.
+ ^
+ | structured data
+ v
+
+ PROTOCOL (serialization, deserialization) accepts structured data for one
+ request, encodes and writes to the medium. Reads bytes from the
+ medium, decodes and allows the client to read structured data.
+ ^
+ | bytes.
+ v
+
+ MEDIUM accepts bytes from the protocol & delivers to the remote server.
+ Allows the protocol to read bytes e.g. socket, pipe, HTTP request.
+
+The domain logic is in `bzrlib.remote`: `RemoteBzrDir`, `RemoteBranch`,
+and so on.
+
+There is also an plain file-level transport that calls remote methods to
+manipulate files on the server in `bzrlib.transport.remote`.
+
+Protocol description
+====================
+
+Version one
+-----------
+
+Version one of the protocol was introduced in Bazaar 0.11.
+
+The protocol (for both requests and responses) is described by::
+
+ REQUEST := MESSAGE_V1
+ RESPONSE := MESSAGE_V1
+ MESSAGE_V1 := ARGS BODY
+
+ ARGS := ARG [MORE_ARGS] NEWLINE
+ MORE_ARGS := SEP ARG [MORE_ARGS]
+ SEP := 0x01
+
+ BODY := LENGTH NEWLINE BODY_BYTES TRAILER
+ LENGTH := decimal integer
+ TRAILER := "done" NEWLINE
+
+That is, a tuple of arguments separated by Ctrl-A and terminated with a
+newline, followed by length prefixed body with a constant trailer. Note
+that although arguments are not 8-bit safe (they cannot include 0x01 or
+0x0a bytes without breaking the protocol encoding), the body is.
+
+Version two
+-----------
+
+Version two was introduced in Bazaar 0.16.
+
+The request protocol is::
+
+ REQUEST_V2 := "bzr request 2" NEWLINE MESSAGE_V2
+
+The response protocol is::
+
+ RESPONSE_V2 := "bzr response 2" NEWLINE MESSAGE_V2
+
+Future versions should follow this structure, like version two does::
+
+ FUTURE_MESSAGE := VERSION_STRING NEWLINE REST_OF_MESSAGE
+
+This is so that clients and servers can read bytes up to the first newline
+byte to determine what version a message is.
+
+For compatibility will all versions (past and future) of bzr clients,
+servers that receive a request in an unknown protocol version should
+respond with a single-line error terminated with 0x0a (NEWLINE), rather
+than structured response prefixed with a version string.
+
+Version two of the message protocol is::
+
+ MESSAGE_V2 := ARGS BODY
+ BODY_V2 := BODY | STREAMED_BODY
+
+That is, a version one length-prefixed body, or a version two streamed
+body.
+
+Version two with streamed bodies
+--------------------------------
+
+An extension to version two allows streamed bodies. A streamed body looks
+a lot like HTTP's chunked encoding::
+
+ STREAMED_BODY := "chunked" NEWLINE CHUNKS TERMINATOR
+ CHUNKS := CHUNK [CHUNKS]
+ CHUNK := CHUNK_LENGTH CHUNK_CONTENT
+ CHUNK_LENGTH := HEX_DIGITS NEWLINE
+ CHUNK_CONTENT := bytes
+
+ TERMINATOR := SUCCESS_TERMINATOR | ERROR_TERMINATOR
+ SUCCESS_TERMINATOR := 'END' NEWLINE
+ ERROR_TERMINATOR := 'ERR' NEWLINE CHUNKS SUCCESS_TERMINATOR
+
+That is, the body consists of a series of chunks. Each chunk starts with
+a length prefix in hexadecimal digits, followed by an ASCII newline byte.
+The end of the body is signaled by 'END\\n', or by 'ERR\\n' followed by
+error args, one per chunk. Note that this allows an 8-bit clean error
+response.
+
+A streamed body starts with the string "chunked" so that legacy clients
+and servers will not mistake the first chunk as the start of a version one
+body.
+
+The type of body (length-prefixed or chunked) in a response is always the
+same for a given request method. Only new request methods introduced in
+Bazaar 0.91 and later use streamed bodies.
+
+Paths
+=====
+
+Paths are passed across the network. The client needs to see a namespace
+that includes any repository that might need to be referenced, and the
+client needs to know about a root directory beyond which it cannot ascend.
+
+Servers run over ssh will typically want to be able to access any path the
+user can access. Public servers on the other hand (which might be over
+http, ssh or tcp) will typically want to restrict access to only a
+particular directory and its children, so will want to do a software
+virtual root at that level. In other words they'll want to rewrite
+incoming paths to be under that level (and prevent escaping using ../
+tricks). The default implementation in bzrlib does this using the
+`bzrlib.transport.chroot` module.
+
+URLs that include ~ should probably be passed across to the server
+verbatim and the server can expand them. This will proably not be
+meaningful when limited to a directory? See `bug 109143`_.
+
+.. _bug 109143: https://bugs.launchpad.net/bzr/+bug/109143
+
+
+Requests
+========
+
+The first argument of a request specifies the request method.
+
+The available request methods are registered in `bzrlib.smart.request`.
+
+**XXX**: ideally the request methods should be documented here.
+Contributions welcome!
+
+
+..
+ vim: ft=rst tw=74 ai
+
=== modified file 'bzrlib/smart/__init__.py'
--- bzrlib/smart/__init__.py 2007-04-26 04:32:44 +0000
+++ bzrlib/smart/__init__.py 2007-09-03 04:43:27 +0000
@@ -20,160 +20,17 @@
rather than being a single large module. Refer to the individual module
docstrings for details.
-Overview
-========
-
-The smart protocol provides a way to send a requests and corresponding
-responses to communicate with a remote bzr process.
-
-Layering
-========
-
-Medium
-------
-
-At the bottom level there is either a socket, pipes, or an HTTP
-request/response. We call this layer the *medium*. It is responsible for
-carrying bytes between a client and server. For sockets, we have the
-idea that you have multiple requests and get a read error because the other side
-did shutdown. For pipes we have read pipe which will have a zero read which
-marks end-of-file. For HTTP server environment there is no end-of-stream
-because each request coming into the server is independent.
-
-So we need a wrapper around pipes and sockets to seperate out requests from
-substrate and this will give us a single model which is consistent for HTTP,
-sockets and pipes.
-
-Protocol
---------
-
-On top of the medium is the *protocol*. This is the layer that deserialises
-bytes into the structured data that requests and responses consist of.
-
-Version one of the protocol (for requests and responses) is described by::
-
- REQUEST := MESSAGE_V1
- RESPONSE := MESSAGE_V1
- MESSAGE_V1 := ARGS BODY
-
- ARGS := ARG [MORE_ARGS] NEWLINE
- MORE_ARGS := SEP ARG [MORE_ARGS]
- SEP := 0x01
-
- BODY := LENGTH NEWLINE BODY_BYTES TRAILER
- LENGTH := decimal integer
- TRAILER := "done" NEWLINE
-
-That is, a tuple of arguments separated by Ctrl-A and terminated with a newline,
-followed by length prefixed body with a constant trailer. Note that although
-arguments are not 8-bit safe (they cannot include 0x01 or 0x0a bytes without
-breaking the protocol encoding), the body is.
-
-Version two of the request protocol is::
-
- REQUEST_V2 := "bzr request 2" NEWLINE MESSAGE_V1
-
-Version two of the response protocol is::
-
- RESPONSE_V2 := "bzr request 2" NEWLINE MESSAGE_V1
-
-Future versions should follow this structure, like version two does::
-
- FUTURE_MESSAGE := VERSION_STRING NEWLINE REST_OF_MESSAGE
-
-This is that clients and servers can read bytes up to the first newline byte to
-determine what version a message is.
-
-For compatibility will all versions (past and future) of bzr clients, servers
-that receive a request in an unknown protocol version should respond with a
-single-line error terminated with 0x0a (NEWLINE), rather than structured
-response prefixed with a version string.
-
-Request/Response processing
----------------------------
-
-On top of the protocol is the logic for processing requests (on the server) or
-responses (on the client).
-
-Server-side
------------
-
-Sketch::
-
- MEDIUM (factory for protocol, reads bytes & pushes to protocol,
- uses protocol to detect end-of-request, sends written
- bytes to client) e.g. socket, pipe, HTTP request handler.
- ^
- | bytes.
- v
-
- PROTOCOL(serialization, deserialization) accepts bytes for one
- request, decodes according to internal state, pushes
- structured data to handler. accepts structured data from
- handler and encodes and writes to the medium. factory for
- handler.
- ^
- | structured data
- v
-
- HANDLER (domain logic) accepts structured data, operates state
- machine until the request can be satisfied,
- sends structured data to the protocol.
-
-Request handlers are registered in `bzrlib.smart.request`.
-
-
-Client-side
------------
-
-Sketch::
-
- CLIENT domain logic, accepts domain requests, generated structured
- data, reads structured data from responses and turns into
- domain data. Sends structured data to the protocol.
- Operates state machines until the request can be delivered
- (e.g. reading from a bundle generated in bzrlib to deliver a
- complete request).
-
- Possibly this should just be RemoteBzrDir, RemoteTransport,
- ...
- ^
- | structured data
- v
-
-PROTOCOL (serialization, deserialization) accepts structured data for one
- request, encodes and writes to the medium. Reads bytes from the
- medium, decodes and allows the client to read structured data.
- ^
- | bytes.
- v
-
- MEDIUM (accepts bytes from the protocol & delivers to the remote server.
- Allows the potocol to read bytes e.g. socket, pipe, HTTP request.
-
-The domain logic is in `bzrlib.remote`: `RemoteBzrDir`, `RemoteBranch`, and so
-on.
+Server-side request handlers are registered in the `bzrlib.smart.request`
+module.
+
+The domain logic is in `bzrlib.remote`: `RemoteBzrDir`, `RemoteBranch`,
+and so on.
There is also an plain file-level transport that calls remote methods to
manipulate files on the server in `bzrlib.transport.remote`.
-Paths
-=====
-
-Paths are passed across the network. The client needs to see a namespace that
-includes any repository that might need to be referenced, and the client needs
-to know about a root directory beyond which it cannot ascend.
-
-Servers run over ssh will typically want to be able to access any path the user
-can access. Public servers on the other hand (which might be over http, ssh
-or tcp) will typically want to restrict access to only a particular directory
-and its children, so will want to do a software virtual root at that level.
-In other words they'll want to rewrite incoming paths to be under that level
-(and prevent escaping using ../ tricks.)
-
-URLs that include ~ should probably be passed across to the server verbatim
-and the server can expand them. This will proably not be meaningful when
-limited to a directory?
+The protocol is described in doc/developers/network-protocol.txt.
+
"""
# TODO: _translate_error should be on the client, not the transport because
=== modified file 'doc/developers/index.txt'
--- doc/developers/index.txt 2007-08-13 10:20:11 +0000
+++ doc/developers/index.txt 2007-09-03 05:11:38 +0000
@@ -31,5 +31,6 @@
* `Repositories <repository.html>`_ |--| What repositories do and are used for.
+* `Network protocol <network-protocol.html>`_ |--| Custom network protocol.
.. |--| unicode:: U+2014
# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWR4/GAIADFP/gHWWQIRx////
//////////VgGw+9m3vZzN93vAaKFfa293Xfe12PRQmmK1uevb3VyM1O333vPWfI51rrxO62hN2P
J4Jb2173D2yLzncR2vZnbdtQ16rvtcEkk0mBMTQAp+RNGU2UwkxNpqbIjGkYmmNIDRoDIJQIBAKa
ajJTYQ1P1R7U1B6T1NPap6QeoAD1B6gA0aASkamQIgDCDQGgbUAADQAAAAAACQkSYqeUxqE8SbUa
epp5NRjU2hNNNNBiaaDTCAABoEURBMgTETT0mmU3pqo3qYwk0nk9JqeobU9T1DIekDIA0AkSBATQ
GiCAaGmiNFP1TemqNtTJG1PUeoAGEA0C4bMaQMzFAIcEAslXDb1v2MHlNJAI/oZhykhfC70d1Dq4
WJHdfHI66S1aOgz6zd+i6YNzPN2y8V0A9OphtHD0+qtG4tEqtoo9SQsh/n965X2JmQ2xnU6utT/H
r5J1RL8J7lHw+P5hLM00wWe62z0tCQFQ6AYHDDQnahackCpmbrCMxsEhZn5oYV/uD1t/GJY8fwaN
fdWO3kFSBoITVKv9+FfF/Crg8C84b5xwJeZxS6vO6AaZ72LhZxtsFfKN6npa/R+VopiejNbf7c09
o0LguohElZSV6gHzc1KEU9qOhjmfYlZa1+QT0Yx8sA2BjLeJi0omtXzNYt/bypHPoNvJmGhc6S3n
ik2GJpJ/Y8L5DuVnECOa0IbBDBHm60nUfm37CGxoaTQ0DYd2RNDDp4uo6CMMxcxnEdEJvt+DhXOM
rMa1rcE+B1Mx+9B3o9CGIG2MbE30Dwe0sd58xL1e9eGC3LDyy2HfGtY8JwV8IKOTMrQVrNjIW1w0
z9NvNmN2q6mQs82wmk2dM30fEmMKVdMWgFVKXHsyaaE6rVcXQ9Pwh5j3GZIb0e2h8h5iRZyrm+dH
lHQINa8lRWJLB2VLOxjCuDpHpVktatfew7HxUIuCwtf2OUoFSWHeaPd3Gkmo/uLQyP7xxP+ZiMR+
7TaSNDetUHGe90ZDYxQPs0CA9/vwJCWiMGFGYpzQKaI60gIcJ7T4ynOV7yGKcOZAQOijPFsUU9F8
ZWsfF7484aYptnKpA8hpdjIOqfsM+NoToRQLU4Ogf3oKKaaavrELlXEqJezKiiSax8cEKBHXX0QM
gpM94sUzMtnyyUW42YzbQ4toxQ1WsExcJJysqHXoCU2ODF1/QXDmVmTScZZ5EjDz+aBjrx1qOuMs
hSItliUiKRst1kiEz6M0nBbT0xdOrsR0l15NVO/mYybae2fCkfPUpi7rOchMC26JFYP+KOE6GG0F
E2RcjrwlH6DNr8VPAtICRIdEtmZulrb7icr2uBuJsKFSWDUDqhygj9A9tU0VeSWMnnB/LKCNJQsJ
uPnr895jL5HCtBjgqJw6zFS1+LlFFruI5pyatkWbNSKoo+qzdfEyHUdjIbiiqu7XFN6tQW+XhUmU
Oc38cjBASwxvkDG3fFR4v0sJOZfwnOVxddFOBVOXVCy05C5MbBxwtLIvI3gaUGqhdPAtU0Kh/6Gq
i0cbPHJJtLZ7w9efTc226Jxjyo+xBHlGSFR4OnJHOacAj7UyVXfSDfF7XljS7ub81Moi+Yrk3FZ4
bBBgV1JhuPpARnVpZtFMSVq94iWwjMZ0Z0+GsiW+k81JkkbF+IZYaqqFZmEpgr6DgrDHvwl3B3q4
wLxm1hlcUnm6qnxznbpdqk00GqR0KL4qPMJE2CIVMryC7B3O7SH/Ep4eY187vJLwRFGJH5KNSCpR
fcKA6Gzd12OQ35aTn8ykStdT6wFWtftXrVBI4obGJjQmWtMufJqIEee/xEAHvYR5GDj7q+yQsz5t
5Wmrd4TtKE/Wf6XvdvrOD/v5Laz7jBsmw46bzplwN1TsKovkdvnQKe8ztO7t532H+KAR0QaiD7D6
e/ds+xtxBC4YJo1ltEokhAwglwh1dKYGQ5mHq2NFfZ3lnXeVSYpXaSuhLVEOg5QpEwGMaa2OfL3M
VyhRNf10raq1zxybXF1pJqYPHuN2eNxpkxRaRPysdO1PBeOKPljdMUBJbAxt2QciNGFWK3JDjmNK
Eh2PGHjBkCOAMrPpPxK3yGmK3tbbBgahv5/d6+rmg6vyWXw02t+BJFJOpd75v6OTe/Jbt+nhZBk1
h619kSTGFD5pJA5mBhsaJzthaIBUqchZBWX6OPlKJkQ/j7gkmcC/2xJJImZGpkXmwH6aYgL0E60Q
VVnDSWBcGDnCJgVbfQhzmGNcdFVBwYAmQRqCoGq1ZBxcN8vFJCVUH21F5FwoEGoN/Z1i7joWNy/6
PuU+grTBguj5Zxz3qFgMMXVjuJymVvBOqGf5pqjX+oR2QroPIemhraL8fYNdS8m5JSKmCgsif1M4
HC/t08wrjGprwltSWF8mgZwSklKsI/A0SNypm4zcEkugpGgDJseHPWrFF4pqyxUsREINL+7dcSJj
MpmhI+pJMv3nm8O1XLcbaviw2dCrJOuHJ3pUFXiyyKiidx2qGJJUxOJE9w1ewgsQoJhORkKgUSXH
qqFsqwffMhAd+ZduRlrYQO/kaHVUWQ/KOTobACwOdD2IZfJGwsZE/3r21R78sb9+5GhKMmUgmQVA
Q5eTwlMDklckEi4NZhqbiag3mWKYaGB1hAzrI0QGBQxSXNS3cylur0yyyH0GcS8vNxI2biCPMUOE
Fihv5GRw3h7IqXhjtw0UYPtX4RySNhVA73Vh1zQ6d9QUu9yM6yEfpHk8CAxqQjW796AI6kpIdJe5
xjWh8GvM+aMu0QNR0TUmgcHIvlBcVB882uiLDUs7OjlncjDgWFlgETriEFUCSytc6uZ0x1F5OV55
GoEiDYJjHAxu53lwXNODxg0ic5MIEtuBLY+gls67O09AUBzZeaSMxWBtqKcjkItYfQqD8qMjlz6X
sL0ZmBK8YtnOZvLWIGGzGC6mRgcRHM5nGDgXlgySTdM8M7XdI4sQNJJUQSnIWyS3U2W2xAfp345z
53c6bmcCpI0TgyREqcjByLGxM3JFJGTUwt1h4MJCInJsHAWx+GR7AN+4qWNmocZGPE0MElKw3JWv
Jz0OIrnAoh5hwJBEMpMeWqsqMDGWZJYvZnPFTIqBS11TkiYw7BpJGzmbF0Oq6q6WxNVd0Ndabewj
AC26jGRLHf8Vio5ucg6CiHaBogEXHTuTuOEjs29XxcmyGQ/EQGQmTed9QPNcJc7B4cYQ41ahyobA
C3rHlcBzMK5SB/KwPxh9/nto7VA4Np8ykTekTjGcanPOgmmMbIrEQ4QaaOrkLmEv3PzIcjnaORkc
Xxy0Zq2FUUjmDpOGY9aqi7iQeYMHH3vrI5RdIyYG9aFZ4yitTjmYMCbGJiG2vOLEybYu0oQLae5S
7GIvkX9L+bo9LDV/+GR6vR69CoaLUPf8t69qxqq9eaREjw8A+Uz7hhqJJR5GWE00edO4fV4X3n6h
/h9kZQxC6xKrXoP8CRVGKQeReUkM2JBrIDckZp459V+XaqHGRsIIMpiH63/jzqHIPEJ97YhapcOR
8v094cCfYwisRSp+pNn2xoPlFWGUXYSiSC8RD41PytGufn8HH6MYjm6LTdMMxhKGMEiQY6vRQqMG
xefeurCUhKtqwdoZff6N2pHaOIYxRQo5EDoKFRzicSSwWsGPj/RkfZw7zrU2G04Eg0Fi7h4gzGPz
z026g1ISvc3IWb0k9HbkMIrEdHXrcyet75JEMBt0DrQMvSJikdqSmRVKpqQH0slYu7BjGefRei+3
M/W0ZwYmvg0g2+BmDTBXlUYMBQFo4HKSYJFAXV6mDNMQjKS4yZusjFfKEqgKhcHk7QKC5kwzRUaR
2sg9vOT0VV8AxWIjSroEfdO9fEF0fx7nIDRX9neXfsSCT3HqgsyAbBl4vZGjgf8zOh4fRtMSnFEc
BsKmMxCZzST0MzPBPbZj114Pcez0vEBdERJsqgCl83kv12xoUPjJgrkejrgXofzTqNRX8iTGiadB
iCAYiiqxQYVxUfIgcpvDQThDDhGk6MayM0xxwbRXQNk+oY3l7m9uWj+xUD0eOPujwYPbICHNz7kI
XNz2jHUpcMVI40JFoBR7XFWFkd9JW0kC59+6hIbnE+CZDwZAmnBBAMVGrK6s4z1yGOlFUg3Wlvpo
3GFhfcvJxK3EKKkNVSIUDVUppNnUALIPkGhcTn1dEasNC6wnCQoF+GEXxg0UgqFzvKwbWDEFmEF6
qFo1aZM52qDbC8M2eEi1xdkM8aj32mKaQvPPS7oFOn2iNpCF+Y4ic4h5CknD+JG3ORnuIywmOGUT
iInLHnH2Na7RMTkZFiyCaoNgaT4IpQtPIWHwbhCeA8cE+xb1dJBXpZLfP6/h5LLAw3iHrqpiQp7o
QxS+TAiE/BahfJkDMglCZjbYaC9ZpJ7uExlXbcdszHCcATDE73mkIUaCAi3aiQJGwISKhhkHzQkc
WR8hrKC+bSshJ0jqyodnWUYVl4iKZ0EbMYDklqBmvXiIg4zI9ckdozIKVWCTK0OTQXBoBcQKyEKq
AX0Vmxee6EaPPalmYBnkpDMwD1zpS61GoicgIoKiRuSFWKVAnGSoqogFWoJwKEyICBjGjshWbnyO
lTb4yDrqUDnMpaOYzZdOo99QicoSTDhSFYCzXkicoqgCA6xHYznQ4HEsflPE6xj5wWvRJhopTmFK
JbmmhOgvHLgag9PHfi86E35+qwKheNi+2jyJ1Mo1Z/EyZ6PNcALDIY4MpZEoQehiVvPM7Bw0r7sM
c2t74xQt3dJbKYsI94Ew37XCLKxZZmolHBvUv2R9KKeseq1UFplWKEHVRIKYmsRdFQLsjIXlNHDJ
bqFmZJKDilFG1rE4JTvOhZHMbYZzKFFBBTAMWSlEtdVfWibG/acfZzIiD6BqBy0rP7qUPV5TynJ+
87Th8DkmHNB1ioHiZVNtjML2xuPqrFEAQLHhjyZALGPMyuMgkoKFWMPOW1MtBts5SV9Tz4XEuDep
yldo0msl0GSrhAPIluj5BhjkN4tPbUiY6rsOg7cJpCsv31vGKQoHga6kLr4nqVzwgIS7LosHYA1f
pUpMwFva+nLtnyjmMyc7sRTO+DNB30gNWgaFUKshBFlUTTEs5b9EoQQ0A2DaDMw3Jj2bbpw5tenB
5Tmiw2qd1FbqGVsDmvNglhIC7Tk1kXIMEvvIGxpg2mhtDRAK8WoxNqV+XGcnorRClDSnfKRLwiVo
NrLmTUbkO0x9iLiBbMRGvFeGEeIKIQdgAYNGtBMu4NBhJwYt40bAB7/uZALQtXBV+TRLZCKQkVHZ
jnEIHKWdXhFiYFpYGeRrcHCP1LYRjh5EXNcY/cPM+1i3UYPAef0/TOw3PPqXMCkkC7ek60DrCQfA
/uHV5ukZUyLfIFI2QEECzAbTcaxoWp0ECHoCd4pzDUx1oNxJ2pNS40mVLWbDwq+C5qG6/7mqeCAK
p0A6i9O9RmAiYZJZSERDldltqAeMGByDoPL16EXaGxoYA2DYk2Ng2nuTAYqZhiOKyMlLgxPeC+g3
MELBZ72JcptOTGxC7nfiv5LgWdQh9lGz21HV1CSFxgTnawcSKdpHUlksN2HQ+1EwDefDnmCtfKC8
VIQce4i8MUleFjjswBED952IKdZnmpCvNEBe22hmwGGvqAI9x9oyyNLEEW3cODj7JSsTMSfNlBnM
oua2L72j2sO1e5bFJcbkmmAmDSAeOQEQsfxDMOfYDv4NIaGNjGDTSXG+YkseD8Sde1ZLOoztEvay
4uvstcTOPKGQtKhnDQshgMdqO/EfIUTV2mj05LTuv17pCZZWY0K9QHQry6fj9z2K90FsGAsQ0GoD
tEHcAVOnChtF/AO6T/ymHY0bRl7IoRBBw1FrWUhBgzWVEGQ0pghIchaDtcOUS1ajpzUa6C/XyuO7
ehSiSybJZSBmfAQpyWxix4Y3MPDBVGnOZvfIRleL5NExclUZjeaBEcdBGNjH5NwVLvj1iazSxSZz
wVW7aoUiWYfbLx7m6tmOy7epaXRNpDJECSIzf6g5fqrIPCndxYSSdfohhM0TOaoEhQJe2rGcJxq6
CvCbPnczQYdYyZhzE1PE9ZUKmiMVcWp6UL5jjAw7YGe93kZ44jMyA2FUSmMZEyG9KbsQIl5+ZhiM
wwwChwaPQMFR5yBdowtA0awIAnwbAjMIuPLFGNwoTqMB1ARimUFgBuzFaWFqTQkXVguhoaYxrEIC
DaZQBPMh0LNAMnJwZDmCMF2UwBKigDKikVczY0fBANnDFwA2uGuUUk0RBHlbW7QjAawBkEQbBgsy
mZDCkFQUACg+1UCq53Q7vR3dU5TOF26USIMGiEESEgz56TYWLDRbERonyl3xbg4WAqF41ai2uwU4
mMMvyJwmKAaRgE0jldDCUQHEYE1onYZSUSDwyo7+xqhcYuxFKYXDgIMxe7sFw1GikqQuXQ56IUUS
FEGwkcigBbmCKiIkLmsAo5IBqp/bmuDbMhx+J1A2kdWxTuAV7BKfHNBLfsFSZd+asDyzEzC5E5aV
1utvLd2enq0U3urfIBbVuXKktzzgGKD8GQWWBdmtidj3MkFwIjbcQYx8pKgUscpFHH5Q46lCvGQB
rdYwyo/LBVgITyjBopy8bqdCxU8jtEG1wb3z8H0efdA0iEbIbsGm2GaIRtjbaafGMqghHTGDGymm
LYLKCLfSd9FHI1YOxoMQDnHWXhJ4mc15ahhtjxKiaXsCjVkuGHAuQkxC20GGD6WutYXa9duKjUU9
RxSZrmUJPNKz4pZhMNzQaDVhCjiAM4D9AhlHtDg0Q0ICyrsDMOxQrYcYlBLh3AM4vcioviBrod2l
ULNGh8SSTYhGjNiWSJMELMPHVkxjY03YTJahagDTEg37oDGR8Xst3uTbBzL57pklxiqBh9Dgu54E
4m2Q43sKoNA12Bkw1NQgScVU+SHgnQgzWhmxMwTnixOvWDNiGOnKPYhLyZwyLRYvTLO5Ywa5dFkz
vWqojBGKsOoMMKd74O6OdaGhLbXQpWE00JHa+Zig8kU2tLpt5NJjLHSx52FLL8x9cxYsTHettoCM
DJWQWXjQWLki63cVc4UqOKOwMGBLiAZGGESElzmQergVu3x5peakLW2hGQPJvcUSNZctQqNPLojS
GcuBGkQxXFhSChvAGL18KAWfU0jVikgufU9vVnkvMNSumUiRNZovhmScyVWGltWrJCcKSJncaUKR
JnoLD0QHczeZdXvbktGlaL30VTvDMHEwkxTbmRNETf6fJ5Vorxez4ZrIWQLA2uyE0lbSuds3x0Eb
G7xcBQ3kKki1GLMBhDx1MJTmpLALFC8RUdwxUSWYpAtixirkeYqxg2A2hJUoUgkecYGArihVcLQQ
liRYXjIbDbdGWpawk2khjvQhbdpIYkdAosxqBqhReQqInuIR8yQoQDdU1uYSDZLq7jJG45KUOBNB
EJMiJIMsyYAkBLI3BsNqYlI1LQCaQT2oCyxGrVWOQeT46bF+Sh43zh0BuFjAoAMgeQQjYqRuwBiL
+WFKVPFr9XMWdzDPqrf0zvQdYGATIZMGezU5MBSukc1nDWPPBoIhE8/jMBqtVcqWamW+OBt5Igc6
JBBrNhDFvlAmO5AfOkpVrZJLRaCB+uQXNmARCRwfUHN2/kOTY2AsNGvhDFJUtIXgHTYhRE5CV6PB
HMBCIS6V7EchmQmtq2d8kQihMwKC1ai9SJaIBgiO/3WVmcnrDsd9CSGqDL1U8QrlLxg4gKsb1UYN
SJHI0qWSqlORG0wJKT0dGCHlA1I4eDw+iJBkCsQMlNmqzGIOIMoq1eQdIMIt9NGIuoP/F3JFOFCQ
Hj8YAg==
More information about the bazaar
mailing list