Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 94331 invoked by uid 500); 12 Sep 2000 16:50:14 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 94318 invoked from network); 12 Sep 2000 16:50:14 -0000 From: "Victor J. Orlikowski" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14782.24235.613601.295046@critterling.garfield.home> Date: Tue, 12 Sep 2000 12:49:47 -0400 To: new-httpd@apache.org Subject: Re: Thoughts on filter-chain composition (Short) In-Reply-To: <6c.2eecd94.26ef70c0@aol.com> References: <6c.2eecd94.26ef70c0@aol.com> X-Mailer: VM 6.76 under Emacs 20.7.1 Reply-To: v.j.orlikowski@gte.net X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Suppose for a moment, we're dealing once again with a handheld device. And suppose that we have hacked up a filter to handle CC/PP (W3C working on it; not a standard yet. Basic idea for those not familiar: Use RDF to specify, in the request headers, the capabilities of a given piece of hardware and client software, such as Java VM level or ability to handle frames or tables). With the CC/PP headers, we'd be able to determine what kinds of encodings the said device could handle, and then perform the needed transcoding via setting up the filter chain in advance. We would have the information on what kind of content the device can handle, and we would have the info from the content on the server (i.e. the headers from the gif image, for example). But, as has been said, this advance setup can only be partially done, since not all the info is encoded in the header of the file to be filtered. So, the filters need to be written in such a manner that, when a given filter runs into a "feature" of the content that it cannot handle, it is able to insert the proper filter into the chain in order to take care of things. Thus does Apache become a transcoding engine. Unfortunately, the question that also rears its head is, "Do we cache the results from the transcoding of this content?" The filters are nice, yes, but the amount of time spent in the transcoding should not be wasted (in that, we perform the *same* content manipulation for each of, say, 4000 requests for the same content, since each request has to pass through the same filter chain). This gets heavy, especially with a lot of graphics manipulation. Just my thoughts, Victor -- Victor J. Orlikowski ====================== v.j.orlikowski@gte.net vjo@raleigh.ibm.com vjo@us.ibm.com