Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-Id: <200108140636.f7E6a3A03532@localhost.localdomain>
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: cocoon-dev@xml.apache.org
Subject: [C2] [2.1-dev] proposed changes to the Source interface
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 13 Aug 2001 23:36:03 -0700
Sender: ovidiu@cup.hp.com

Hi,

I was looking at how the current Source interface is defined, and I
believe we need to separate things a little bit more. I badly need
this separation in one of the extensions to Cocoon I'm working on
(which I hope to present sometime early next month).

There are three distinct things the Source interface deals with right
now:

a) the real input source, its last modified date, and content length

b) determining whether the source is a file, and obtaining the file

c) streaming the content of the source to a ContentHandler

d) the ability to refresh a Source

IMO the Source interface should deal only with a). Source should be an
abstraction for content, with no regard whether is a file or whether
it contains XML data.

By greping the sources really quick, I found that the only place that
uses the file characteristics of Source is in
DirectoryGenerator. However a simple workaround can be implemented, by
asking the Source for its system id, and determining from there the
type of the Source.

The functionality defined in c) is already provided by XMLFragment,
and I see no reason why we shouldn't use this instead. Also we should
make a separation between Sources that contain XML data, and those
that don't.

As for point d), I'm not sure is good to assume that all the Sources
are mutable. I have actually come up with Source objects which are
imutable, and for them the refresh operation has no meaning.

As a result, I propose to have Source be following interface:

public interface Source {
  /*** BTW, why use long and not Date? ***/
  long getLastModified();

  long getContentLength();

  public InputSource getInputSource() throws IOException;

  String getSystemId();

  /*** getInputStream() can be easily implemented as
  getInputSource().getByteStream(). ***/
}

Based on this, we can define XMLSource as:

public interface XMLSource extends Source, XMLFragment
{
}

and rename stream(ContentHandler) to toSAX(ContentHandler). The
stream(XMLConsumer) can be implemented based on the toSAX() method
easily.

The URLSource and SitemapSource can then become classes that implement
the XMLSource interface. The refresh method can be placed as a public
method in URLSource and SitemapSource, if they don't prove worth of
creating a new interface. I still need to look into this a little bit
more.

I'm willing to do all the refactoring work if you guys like the
approach. Please let me know so I can finish the work and post a patch
this week; next two weeks I'll be on vacation ;-)

Greetings,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://orion.nsr.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org