Re: Defining Source Interfaces

[Sylvain Wallez]

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().

/** 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.

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.

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.

Carsten, I also some remarks/questions about your changes in Excalibur :
- should parent/child traversal be defined on Source. IMO, a Source
should be kept very simple and basic as not all sources are traversable,

Yes, that is true. But always doing an instanceof is not the best advice
for doing OOP. So, I thought of adding the most common methods to the base
interface and only use extending interfaces if required.

I like Avalon because of the separation of the contracts. If you implement
a component, you don't have to implement all lifecycle methods like
EJBs. If you implement a source you only need to implement the IFs that
you need.

Yep. The beauty of Avalon comes from it's "Zen-itude" : each interface provides the minimal but sufficient set of methods.

Sylvain

--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]