On Sat, 2008-11-15 at 14:49 +0100, Oleg Kalnichevski wrote:
> On Sat, 2008-11-15 at 13:52 +0100, Thorsten Scherler wrote:
> > On Sat, 2008-11-15 at 12:37 +0100, Oleg Kalnichevski wrote:
> > > Folks
> > >
> > > I can't help thinking Handler is a bit too generic and not descriptive
> > > enough. How do you feel about renaming it to ContentHandler or some
> > > such?
> >
> > I chatted with Henri about this a while @apachecon. We came to the
> > conclusion that the current API is to open:
> > public interface Handler {
> > /**
> > * @param openStream
> > * the underlying stream
> > * @param uri
> > * the uri we are currently processing
> > * @param parse
> > * the parse object from a former processing step
> > * @throws Exception
> > */
> > void handle(InputStream openStream, URI uri, Parse parse)
> > throws IOException, DroidsException;
> > }
> >
> > We have access to the parse object, the original stream and the underlying
> > URI.
> > Back in the days I thought it was a good idea since every possible usecase
> > could
> > be handled but maybe we it is way too brought.
> >
> > So maybe we want have different type of handlers:
> > - content handler (using parse)
> > - stream handler (using the openStream)
>
> BTW, would it be okay to replace InputStream parameter with
> ContentEntity? It may also be useful to have access to entity's MIME
> type and charset in some Handler implementations
see my other mail. Maybe the contentEntity can be extended to contain
the result of the parser stage as well.
wdyt?
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
Open Source Java <consulting, training and solutions>
