svn commit: r1043395 - in /websites/staging/mina/trunk/content: ./ mina-project/userguide/ch5-filters/ch5.3-compression-filter.html

[bu...@apache.org]

Author: buildbot
Date: Tue Apr  9 12:52:51 2019
New Revision: 1043395

Log:
Staging update by buildbot for mina

Modified:
    websites/staging/mina/trunk/content/   (props changed)
    websites/staging/mina/trunk/content/mina-project/userguide/ch5-filters/ch5.3-compression-filter.html

Propchange: websites/staging/mina/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue Apr  9 12:52:51 2019
@@ -1 +1 @@
-1857118
+1857192

Modified: websites/staging/mina/trunk/content/mina-project/userguide/ch5-filters/ch5.3-compression-filter.html
==============================================================================
--- websites/staging/mina/trunk/content/mina-project/userguide/ch5-filters/ch5.3-compression-filter.html (original)
+++ websites/staging/mina/trunk/content/mina-project/userguide/ch5-filters/ch5.3-compression-filter.html Tue Apr  9 12:52:51 2019
@@ -204,7 +204,13 @@ h2:hover > .headerlink, h3:hover > .head
 <p>When the filter is added to the chain, instances of the deflater and inflater are created and injected into the session's attributes. This could change, as each session has its own instance of the filter in its chain, so there is no reason not to store those instances in the filter itself.</p>
 <h2 id="side-notes">Side notes<a class="headerlink" href="#side-notes" title="Permanent link">&para;</a></h2>
 <p>The way this filter works does not lmake it very efficient. It requires that the received data to be decompressed are fully read - and there are no control that it's the case of not -, and it also requires that the data to be compressed be fully compressed in one pass, which is quite inneficient from the memory perspective, as we may compress data by blocks, and send them immediately, waiting for the block to be really sent to compress the next one.</p>
-<p>All in all, it's a brittle filter, you'd better not use it !</p>
+<p>One more thing: there is no way this filter can be used to compress something like a file or anythiong that is not contained in a <em>IoFilter</em>. This is a pretty strong limitation.</p>
+<p>All in all, it's a brittle filter, you'd better not use it as it is!</p>
+<h2 id="future-improvements">Future improvements<a class="headerlink" href="#future-improvements" title="Permanent link">&para;</a></h2>
+<p>So we need a compression filter that does not eat all the memory,  possibly a stateless one - why dshould we  have to create as many instances as w ehave sessions ? -, that is fast, AL 2.0 compatible, and that can flush data pieces by pieces.</p>
+<h3 id="stateless-compressiondecompression">Stateless compression/decompression<a class="headerlink" href="#stateless-compressiondecompression" title="Permanent link">&para;</a></h3>
+<p>The idea is to have a function that can be called statically, with a context. It's not necessarily complex  we just need to keep track of a context.</p>
+<p>It should be possible top compress a block of data, send it, and process the next block when the first block has been processed. Same thing with received data: it should be possible to process a buffer, decompress it and wait for the remaining bytes until a block of data has been fully decompressed.</p>
 
 
     <div class="nav">