You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: DEVELOPERS.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -317,7 +317,7 @@ After the upload has finished, check the live pages:
317
317
318
318
* Automatic reconnection
319
319
* Configurable WAMP connecting transports
320
-
* WAMP Connection abstration
320
+
* WAMP Connection abstraction
321
321
* Authentication
322
322
323
323
**0.10** will get into "maintenance mode" after **0.10.6**. We'll have a maintenance branch for that over some time. The new development will be based on **0.11** (see below).
Copy file name to clipboardExpand all lines: README.rst
+1-1
Original file line number
Diff line number
Diff line change
@@ -209,7 +209,7 @@ Autobahn contains **NVX**, a network accelerator library that provides SIMD acce
209
209
210
210
.. note:
211
211
212
-
NVX lives in namespace `autobahn.nvx` and currently requires a x86-86 CPU with at least SSE2 and makes use of SSE4.1 if available. The code is written using vector instrinsics, should compile with both GCC and Clang,and interfaces with Python using CFFI, and hence runs fast on PyPy.
212
+
NVX lives in namespace `autobahn.nvx` and currently requires a x86-86 CPU with at least SSE2 and makes use of SSE4.1 if available. The code is written using vector intrinsics, should compile with both GCC and Clang,and interfaces with Python using CFFI, and hence runs fast on PyPy.
Copy file name to clipboardExpand all lines: docs/wamp/programming.rst
+3-3
Original file line number
Diff line number
Diff line change
@@ -160,7 +160,7 @@ Many of the examples in this documentation use a decorator style with fixed, sta
160
160
161
161
It is important to remember that :class:`Component` handles re-connection -- this implies there are times when your component is **not** connected. The `on_join` handlers are run whenever a fresh WAMP session is started, so this is the appropriate way to hook in "initialization"-style code (`on_leave` is where "un-initialization" code goes). Note that each new WAMP session will use a new instance of :class:`ApplicationSession`.
162
162
163
-
Here's a slightly more complex example that is a small `Klein`_ Web application that publishes to a WAMP session when a certian URL is requested (note that the Crossbario.io router supports `various REST-style integrations <https://crossbar.io/docs/HTTP-Bridge/>`_ already). Using a similar pattern, you could tie together two or more :class:`Component` instances (even connecting to two or more *different* WAMP routers).
163
+
Here's a slightly more complex example that is a small `Klein`_ Web application that publishes to a WAMP session when a certain URL is requested (note that the Crossbario.io router supports `various REST-style integrations <https://crossbar.io/docs/HTTP-Bridge/>`_ already). Using a similar pattern, you could tie together two or more :class:`Component` instances (even connecting to two or more *different* WAMP routers).
164
164
165
165
.. _Klein: https://github.com/twisted/klein
166
166
@@ -438,7 +438,7 @@ A *Publisher* publishes events to topics by providing the topic URI and any payl
438
438
439
439
*Subscribers* subscribe to topics they are interested in with *Brokers*. *Publishers* initiate publication first at a *Broker*. *Brokers* route events incoming from *Publishers* to *Subscribers* that are subscribed to respective topics.
440
440
441
-
The *Publisher* and *Subscriber* will usually run application code, while the *Broker* works as a generic router for events thus decoupling *Publishers* from *Subscribers*. That is, there can be many *Subscribers* written in different languages on different machines which can all receive a single event published by an independant *Publisher*.
441
+
The *Publisher* and *Subscriber* will usually run application code, while the *Broker* works as a generic router for events thus decoupling *Publishers* from *Subscribers*. That is, there can be many *Subscribers* written in different languages on different machines which can all receive a single event published by an independent *Publisher*.
442
442
443
443
444
444
.. _subscribing-to-topics:
@@ -655,7 +655,7 @@ Before any logging happens of course you must activate the logging system. There
655
655
656
656
If you have instead got your own log-starting code (e.g. ``twistd``) or Twisted/asyncio specific log handlers (``logging.Handler`` subclass on asyncio and ``ILogObserver`` implementer under Twisted) then you will still get |Ab| and `Crossbar`_ messages. Probably the formatting will be slightly different from what ``txaio.start_logging`` provides. In either case, **do not depend on the formatting** of the messages e.g. by "screen-scraping" the logs.
657
657
658
-
We very much **recommend using the ``txaio.start_logging()`` method** of activating the logging system, as we've gone to pains to ensure that over-level logs are a "no-op" and incur minimal runtime cost. We achieve this by re-binding all out-of-scope methods on any logger created by ``txaio.make_logger()`` to a do-nothing function (by saving weak-refs of all the loggers created); at least on `PyPy`_ this is very well optimized out. This allows us to be generous with ``.debug()`` or ``.trace()`` calls without incurring very much overhead. Your Milage May Vary using other methods. If you haven't called ``txaio.start_logging()`` this optimization is not activated.
658
+
We very much **recommend using the ``txaio.start_logging()`` method** of activating the logging system, as we've gone to pains to ensure that over-level logs are a "no-op" and incur minimal runtime cost. We achieve this by re-binding all out-of-scope methods on any logger created by ``txaio.make_logger()`` to a do-nothing function (by saving weak-refs of all the loggers created); at least on `PyPy`_ this is very well optimized out. This allows us to be generous with ``.debug()`` or ``.trace()`` calls without incurring very much overhead. Your Mileage May Vary using other methods. If you haven't called ``txaio.start_logging()`` this optimization is not activated.
Copy file name to clipboardExpand all lines: docs/work/README.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@
8
8
9
9
* performance (passthrough of app payloads, general zero copy)
10
10
* support end-to-end encryption
11
-
* carrying proprietory binary payloads (MQTT)
11
+
* carrying proprietary binary payloads (MQTT)
12
12
* strict static typing of interfaces
13
13
14
14
---
@@ -44,13 +44,13 @@ The approach taken (**XX**) allows for a number of useful features:
44
44
45
45
1. flexible support of popular dynamically typed serializers, namely: JSON, MsgPack, CBOR and UBJSON
46
46
2. allow arbitrary adhoc extensibility (as the router basically does not care about new app payloads)
47
-
3.transparantly translate the *application payload* between serialization formats used by different clients connected at the same time.
47
+
3.transparently translate the *application payload* between serialization formats used by different clients connected at the same time.
48
48
4. support optional router side application payload validation: both static, and dynamic (calling into user supplied payload validators)
49
49
50
50
However, a number of downsides have become apparent as well:
51
51
52
52
1. resource consumption: serialization/deserialization can eat significant chunks of CPU, and produce GC pressure
53
-
2. legacy (MQTT) and proprietory payloads that should simply be transported "as is" (passthrough, without ever touching)
53
+
2. legacy (MQTT) and proprietary payloads that should simply be transported "as is" (passthrough, without ever touching)
54
54
3. as apps and systems get larger and more complex, the dynamic typing flexibility turns into a major problem: **the internal and external interfaces and APIs in a microservices based application must be relied upon and their evolution actively managed**
55
55
56
56
The latter does not mean an "either or" question. You can have important base APIs and external interfaces defined rigorously, using static, strict typing discipline, while at the same time have other parts of your system evolve more freely, basically allowing weakly and dynamically typed data exchange - for limited areas.
@@ -60,7 +60,7 @@ The latter does not mean an "either or" question. You can have important base AP
60
60
61
61
### Payload Transparency Mode
62
62
63
-
**Payload Transparancy Mode (PTM)** adds a 4th application payload variant to above **XX**
63
+
**Payload Transparency Mode (PTM)** adds a 4th application payload variant to above **XX**
0 commit comments