On Thu, 9 Jan 2003, Carsten Ziegeler wrote:
>
> Stephan Michels wrote:
> > Carsten Ziegeler wrote:
> > >
> > > Now, think if an implementation for copy(). Each Source implementation
> > > must test if the destination is the same source implementation or not.
> > > If not use IS/OS if yes use opt
Stephan Michels wrote:
About the move() and copy() methods, I don't know if they should be kept
in the new incarnation of this interface.
:-/ not another MoveableSource ;-)
ROFL !!!
;-)
Seriously, are these methods of real use ?
I thought that these methods could be a good start for a
Carsten Ziegeler wrote:
Now, think if an implementation for copy(). Each Source implementation
must test if the destination is the same source implementation or not.
If not use IS/OS if yes use optimized etc.
agreed.
So, if we are using these "marker" interfaces for all other parts, I
really t
Stephan Michels wrote:
> Carsten Ziegeler wrote:
> >
> > Now, think if an implementation for copy(). Each Source implementation
> > must test if the destination is the same source implementation or not.
> > If not use IS/OS if yes use optimized etc.
>
> agreed.
>
> > So, if we are using these "m
Giacomo Pati wrote:
On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
Sylvain Wallez wrote:
What do you think about the ModifiableSource in Excalibur? (That should be
the replacement for WriteableSource - please let *me* win this time ;) )
Sylvain is hard to beat somtimes, I can tell from expe
> Stephan Michels wrote:
>
> >On Wed, 8 Jan 2003, Sylvain Wallez wrote:
> >
> >>>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
> >>d
On Wed, 8 Jan 2003, Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
> >Sylvain Wallez wrote:
> >
> >
>
>
>
> >>And as far as code cleanliness is concerned, an "instanceof" test seems
> >>more OOP to me than a isTraversable() method that tells us if is we have
> >>the right to use getParent() an
On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
> > >
> > >The problem is, if you are using getInputStream/getOutputSteam to copy
> > >a file in a slide repository, that all metadata informations get lost. On
> > >the other hand, if you are using an external SourceUtil to cop
Giacomo Pati wrote:
> > And here is the definitiv answer from the avalon team:
> >
> > "Remember that this is component-oriented programming (COP) and
> not OOP".
> >
> > :)
>
> C'mon. LifecycleHelper is the master batch of COP and not a "normal"
> class!
>
:) Yes, I know - but if you look at m
On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
>
>
> > -Original Message-
> > From: Stephan Michels [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 08, 2003 3:47 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Defining Source Interfaces
> &
On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
>
> Sylvain Wallez wrote:
>
> What do you think about the ModifiableSource in Excalibur? (That should be
> the replacement for WriteableSource - please let *me* win this time ;) )
Sylvain is hard to beat somtimes, I can tell from experience ;)
Giacomo
Sylvain Wallez wrote:
> >
> >The problem is, if you are using getInputStream/getOutputSteam to copy
> >a file in a slide repository, that all metadata informations get lost. On
> >the other hand, if you are using an external SourceUtil to copy a file,
> >you can't hide all implementation details.
>
Stephan Michels wrote:
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
> >>About the move() and copy() methods, I don't know if they should be kept
> >>in the new incarnation of this interface.
> >
> >:-/ not another MoveableSource ;-)
>
> ROFL !!!
;-)
> Seriously, are these methods of real use ?
I thought that these methods could be a good start for a cms
webpor
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Aren't we all a little bit mad to send dozen of mails for a bunch of
methods ;-P
And the real fun has just started: finding the correct name of something!
Yuppie!
BTW: How are our current blocks called now? (no, no, please don't take this
as ser
Stephan Michels wrote:
On Wed, 8 Jan 2003, Sylvain Wallez wrote:
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
dictionary.com makes me prefer
Sylvain Wallez wrote:
>
> Aren't we all a little bit mad to send dozen of mails for a bunch of
> methods ;-P
>
And the real fun has just started: finding the correct name of something!
Yuppie!
BTW: How are our current blocks called now? (no, no, please don't take this
as serious).
Carsten
---
> > 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 (
Nicola Ken Barozzi wrote:
Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I
would suggest to mimic what's in the DirectoryGenerator, that
makes the assumption that the Sou
On Wed, 8 Jan 2003, Sylvain Wallez wrote:
> >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
> dictionary.com makes me prefer hierarchical...
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 Hie
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
And as far as code cleanliness is concerned, an "instanceof" test seems
more OOP to me than a isTraversable() method that tells us if is we have
the right to use getParent() and getChildren(). With a separate
interface, these methods do not exi
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> >>MHO: It all depends on what a Source is.
> >>
> >>1 - If a source is a plug to a URI-based source handler, it should have
> >>children.
> >>2 -If it's a plug to a resource, it should not.
> >>
> >>Usually a source is (2), but since we bin
Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I would
suggest to mimic what's in the DirectoryGenerator, that makes the
assumption that the Source is a file. You can then u
> -Original Message-
> From: Stephan Michels [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 08, 2003 3:47 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Defining Source Interfaces
>
>
>
>
> > > And as far as code cleanliness is concerned, an "i
> > And as far as code cleanliness is concerned, an "instanceof" test seems
> > more OOP to me than a isTraversable() method that tells us if is we have
> > the right to use getParent() and getChildren(). With a separate
> > interface, these methods do not exist if they do not make sense.
> >
> T
Sylvain Wallez wrote:
>
> Okay. Let me throw in more arguments ;-)
>
Great!
> How many protocols do we have for which parent and children make sense ?
> Actually 2 : 'file' and 'slide' (and 'cvs' soon). For other protocols
> such as 'cocoon', 'resource', 'blob', 'xmldb', 'http', etc, this has no
Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I would
suggest to mimic what's in the DirectoryGenerator, that makes the
assumption that the Source is a file. You can then u
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I would
suggest to mimic what's in the DirectoryGenerator, that makes the
assumption that the Source is a file. You can then use all the
facilities g
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
> > Sylvain Wallez wrote:
> >
> [...]
> >>You're totally on track. If you need this action right now, I would
> >>suggest to mimic what's in the DirectoryGenerator, that makes the
> >>assumption that the Source is a file. You can then use all th
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
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 the
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I would
suggest to mimic what's in the DirectoryGenerator, that makes the
assumption that the Source is a file. You can then use all the
facilities given by File.
And we only ar
Sylvain Wallez wrote:
>
> Nicola Ken Barozzi wrote:
>
>
>
> > I really don't understand much of the heat in this discussion because
> > I'm not so into it, but I'm happy you guys are and are making
> progress :-)
>
>
> Thanks. Actually, the discussions is about many points, one after the
Nicola Ken Barozzi wrote:
I really don't understand much of the heat in this discussion because
I'm not so into it, but I'm happy you guys are and are making progress :-)
Thanks. Actually, the discussions is about many points, one after the
other ;-)
I just wanted to ask for a second (plea
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
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. Wh
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
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 i
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()-
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
However, I still consider the new implementation of
SourceResolverImpl.release() in Excalibur (dated 15 dec. and not
currently in Cocoon) to be a performance burden since in most cases all
component-related operations it performs *will be useles
Sylvain Wallez wrote:
>
> However, I still consider the new implementation of
> SourceResolverImpl.release() in Excalibur (dated 15 dec. and not
> currently in Cocoon) to be a performance burden since in most cases all
> component-related operations it performs *will be useless*.
>
> Carsten,
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
...
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.
Do you mean recycle()? There is no release() in Source...
I was referring to SourceResolver.rel
Sylvain Wallez wrote:
...
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.
Do you mean recycle()? There is no release() in Source...
If you've meant recycle(), look no further than into SitemapSourc
On Mon, 6 Jan 2003, Sylvain Wallez wrote:
> Stephan Michels wrote:
>
> >On Mon, 6 Jan 2003, Sylvain Wallez wrote:
> >
> >>Stephan Michels wrote:
> >>
> >>
> > /** Return the parent source. Returns null if the source hasn't a
> >parent. */
> > public Source getParentSource() throw
Stephan Michels wrote:
On Mon, 6 Jan 2003, Sylvain Wallez wrote:
Stephan Michels wrote:
/** 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
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
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
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
I think it's time to define the WriteableSource etc. interfaces
for the excalibur source package and move them out of Cocoon.
What do you think about this? This would move the responsibility
to excalibur :)
I guess you'
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 o
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> >I think it's time to define the WriteableSource etc. interfaces
> >for the excalibur source package and move them out of Cocoon.
> >
> >What do you think about this? This would move the responsibility
> >to excalibur :)
> >
>
> I guess you'
Carsten Ziegeler wrote:
I think it's time to define the WriteableSource etc. interfaces
for the excalibur source package and move them out of Cocoon.
What do you think about this? This would move the responsibility
to excalibur :)
Given the current state of Avalon, and more of excalibur, I wo
Sylvain Wallez wrote:
While working on sources recently (the CVSSource I'm about to publish)...
Hip Hip Hooray!
Wonderful, Sylvain.
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
>
> While working on sources recently (the CVSSource I'm about to
> publish),
Yay!
:)
J.
===
Information in this email and any attachments are confidential, and may
not be c
Carsten Ziegeler wrote:
I think it's time to define the WriteableSource etc. interfaces
for the excalibur source package and move them out of Cocoon.
What do you think about this? This would move the responsibility
to excalibur :)
I guess you're joking, but is this good or bad ? Who else besi
On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
>
>
> > -Original Message-
> > From: Stephan Michels [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 06, 2003 3:44 PM
> > To: Cocoon-Dev
> > Subject: Re: Defining Source Interfaces
> >
> >
> -Original Message-
> From: Stephan Michels [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 06, 2003 3:44 PM
> To: Cocoon-Dev
> Subject: Re: Defining Source Interfaces
>
>
>
>
> On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
>
> > I think it&#
On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
> I think it's time to define the WriteableSource etc. interfaces
> for the excalibur source package and move them out of Cocoon.
>
> What do you think about this? This would move the responsibility
> to excalibur :)
>
> I added before christmas the po
I think it's time to define the WriteableSource etc. interfaces
for the excalibur source package and move them out of Cocoon.
What do you think about this? This would move the responsibility
to excalibur :)
I added before christmas the possibility to retrieve children
of a source to the Source in
57 matches
Mail list logo
