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 15:50:10 GMT

Sylvain Wallez wrote:
> Following Stephen's example, I grep'ed instanceof on the whole 2.1
> source base and found... 388 of them !
And how many of them are *not* because of Avalon?

> >Anyway, I think your arguments are better than mine (sniff).
> >
> >So, we have a TraversableSource or HierarchicalSource or ...?
> >
> >
> I'm not a native speaker, but the definition of traversable given by
> makes me prefer hierarchical...

> Ah, and what about adding an "exists()" method on Source (it's currently
> on WriteableSource) ? That one makes sense and is really useful, as the
> current way to know if an URI exists is to try to getInputStream(),
> which can be heavy.

> >What do you think about the ModifiableSource in Excalibur? (That
> should be
> >the replacement for WriteableSource - please let *me* win this time ;) )
> >
> >
> Hey, you won on the SourceFactory.release() !
Ah, yes - I forgot that. :)
> But I don't want to count points or judge anyone/anything. I just want
> things to be nice, and, well, we sometimes have different feelings about
> what is nice ;-)
Absolutely, and (you know me) I only meant this as a joke. It's not
who is right, but it's important that we come to the "right" solution.

> I'm not sure about the "Modifiable" name. Maybe I'm biased because it
> was formerly (in 2.0) used to name something else ? Don't you like
> "WriteableSource", or "OutputSource" ? Don't know...
Ok, you're right with Modifiable and actually I didn't like WriteableSource
because you don't write directly to the source but to the OutputStream
provided by the Source.

> Whatever its name, it would be good for this interface to have the
> canCancel() and cancel() that are on WriteableSource. These allow data
> that has been written to a source to be discarded if something goes
> wrong. This is especially usefull in pipelines using the SWT for example.
Ah yes, these were the methods I wanted to ask about - ok, if they are
important we can add them.

> About the move() and copy() methods, I don't know if they should be kept
> in the new incarnation of this interface.
I don't think that they are important. A copy is a read/write action and
a move a read/write/delete action. We could make an utility class providing
support for it (and this would allow an inter source moving. wow!).


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

View raw message