On Mon, 6 Jan 2003, Sylvain Wallez wrote:
> Stephan Michels wrote:
>
> >On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
> >
> >>>>I added before christmas the possibility to retrieve children
> >>>>of a source to the Source interface in excalibur and started
> >>>>with the ModifiableSource interface (= WriteableSource).
> >>>>
> >>>>What else do we need? I think we have a buch of extensions
> >>>>to the Source interface.
> >>>>
> >>>Well, look in the 2.1 scratchpad where there's a lot of yummy stuff :
> >>>TraversableSource, VersionableSource, LockableSource, etc.
> >>>
> >>>While working on sources recently (the CVSSource I'm about to publish),
> >>>I found the current definition of TraversableSource not intuitive, and
> >>>modified it so it's more like to java.io.File :
> >>>
> >>>public interface TraversableSource extends Source {
> >>>
> >>> /** Is the source a directory or a collection ? */
> >>> public boolean isSourceCollection() throws ProcessingException,
> >>>IOException;
> >>>
> >>> /** Returns the collection of child sources. */
> >>> public Collection getChildren() throws ProcessingException,
> >>>IOException;
> >>>
> >>> /** Returns the local name of this source */
> >>> public String getName() throws ProcessingException, IOException;
> >>>
> >>>
> >
> >getLocalId() ??? because of getSystemId()?
> Look at java.io.File : you have getPath() and getName(), not getLocalPath().
http://jakarta.apache.org/commons/sandbox/vfs/apidocs/org/apache/commons/vfs/FileObject.html
used also getName(). hmm.
> >>> /** Return the parent source. Returns null if the source hasn't a
> >>>parent. */
> >>> public Source getParentSource() throws ProcessingException,
> >>>IOException;
> >>>}
> >>>
> >>>
> >
> >I don't return Sources, because Sources can be Components, which
> >must be resolved/released by the SourceResolver.
> >So I think returning the URI instead of the Sources is a must-have.
> >
> >
>
> I disagree : the SourceResolver is used to get a Source from its URL,
> but a Source is not a component : the component is the SourceFactory
> that creates Source instances. A source itself is not managed by a
> ServiceManager.
But can managed by the SourceResolver.
> Also, having to hop through the SourceResolver to get parents or
> children of a Source *really hits performance*, as each call to
> resolve() looks up/releases the factory, asks it to create the source,
> etc, etc.
But if the creation of the Sources is expensive, is is easier to create
a SourceResolver, which holds a pool of the sources.
> Looking at all traversable sources I know of (Slide source and my
> yet-unpublished CVSSource and TraversableFileSource), getting the
> children or parents Source objects is really trivial and lightweight
> compared to the processing required if we go through the SourceResolver.
>
> Furthermore, I'm really wondering now if we need to release() a Source,
> as I can't find any implementation that actually does something of it.
>
> And I don't think an implementation will ever use it : the point where
> something has to be released in Sources is related to stream methods
> (look at BlobSource.getInputStream()). Also, these methods can be called
> several times during the lifetime of the Source object, and their result
> can last longer than the Source object's lifetime (look at
> XSLTProcessorImpl.resolve()).
>
> And releasing a Source involves once more a look up/release of the
> SourceFactory to actually do nothing...
>
> So, considering that the SourceResolver is one of the most used
> components, removing release() from this interface may lead to a
> significant performance increase.
That can be, but a resolve/release has much cleaner lifecycle. For
example, if the Source lookup for a component using the componentmanager,
which got the Source by the Composable contract, the component must
release the component, if the Source were disposed.
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
