On Sat, 2008-11-15 at 16:23 +0100, Thorsten Scherler wrote:
> 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?
>
Works for me. Do you wan me to take a stab at it?
Oleg
> salu2
