Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: AbstractResourceReader?
Date: Wed, 2 Mar 2005 15:38:33 +0100
Message-ID: <5E091A68F794974CAF431CA31F5AF2CC11EA0A@server.bizzdesign.nl>
Thread-Topic: AbstractResourceReader?
thread-index: AcUfNYJtVaILcDwXQY6fIryYnXCLbQ==
From: "Bart Molenkamp" <b.molenkamp@bizzdesign.nl>
To: <dev@cocoon.apache.org>

Hi,

A while ago I was discussing how to build a reader that could get it's
input stream from the context object using JXPath. It gets the following
information from the context object using configurable Xpath
expressions:
- the content stream
- the mime type
- the content length

I've created the reader by simply copying the existing ResourceReader
and replaced all the code where a Source was used to use the content
input stream, the content length and the content type that are passed in
the context object.

The reader is working this way, but I was wondering if it makes sense to
create another abstract reader that handles things that are common to
the ReasourceReader and the StreamReader (the reader I've created). It
concers many HTTP specific code such as byte range, content expiration,
etc. I've used all that code (only difference is that my reader isn't
cacheable, don't know how to generate a key yet).

Can someone tell me what code would be common (as I don't have specific
knowledge about these http byte range, expiration etc things), or if it
doesn't make sense at all.

Bart.