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, this interface was always meant to be more generic than just a
content processor? I see now.
> So maybe we want have different type of handlers:
> - content handler (using parse)
> - stream handler (using the openStream)
> - uri handler (using the uri)
>
I think there are cases where those bits are not mutually exclusive and
one may want to have them all, or at least more than one representation.
Oleg
> The super interface could look like
> public interface Handler {
> void handle(Object object)
> }
>
> WDYT?
>
> salu2
