cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: Defining Source Interfaces
Date Wed, 08 Jan 2003 11:39:58 GMT

Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> >Sylvain Wallez wrote:
> >
> >
> >>The performance problem is that among all implementations of
> Source that
> >>I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource,
> >>SitemapSource and CVSSource), only one actually needs to be disposed
> >>(SitemapSource).
> >>
> >>So having a isSelectable()-select()-release() cycle to call a
> >>factory.release() that does nothing most of the time seems CPU
> >>waste to me.
> >>
> >>Now I agree that theoretically releasing is the factory's job. So, in
> >>order to lower my performance fears, what about removing the
> >>isSelectable() call in SourceResolverImpl.release() ? It would
> remove an
> >>unnecessary search in the ServiceSelector HashMaps, considering also
> >>that the select() that follows this isSelectable() is surrounded by a
> >>try/catch.
> >>
> >>
> >>
> >Wow, entering twilight zone...believe it or not, I just thought of this
> >yesterday evening when I tried to think about some general performance
> >improvements.
> >Actually, I wasn't sure about it, because if we are honest, it's a hack.
> >
> Why is it a hack ? Calling isSelectable() is only of real use if the
> probability for it to return false is important and if you can make some
> corrective actions in that case.
Ok, hack is perhaps a too hard formulated. Anyway, I think we can live with
and change it.

> >And throwing/catching exceptions is also a little bit time consuming.
> >But as a (better?) solution I would like to make a factory for the
> >URLSource as well - so all sources are handled by a factory and the
> >select() call will always return a factory - and this will avoid
> >the isSelectable() call.
> >What do you think about this?
> >
> Twilight zone again ;-)
> I wanted to raise this issue just after we finished with that one,
> because it seemed to me unclean for URLSource to be managed directly by
> the SourceResolver and not through a factory.
> >Ah, btw you're right that the Source object should return a Collection
> >instead of an Iterator for the children - I will fix that, too, asap.
> >
> Cool. But I'm still not that happy with these methods being on Source
> itself. What about TraversableSource or HierarchicalSource (I have this
> last one ready on my PC with collections) ?
I really don't like all these instanceof tests and I think that a source
can have children is very common. So if you deal with sources you always
end up with a test if this source contains children or not.
I think this test is much more cleaner/nicer/whatever if I can directly
query the source. An instanceof test for this reason is not appropriate.


To unsubscribe, e-mail:
For additional commands, email:

View raw message