Return-Path: 
 <cocoon-dev-return-34812-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 95109 invoked by uid 500); 8 Jan 2003 16:40:06 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 95030 invoked from network); 8 Jan 2003 16:40:04 -0000
X-Authentication-Warning: vern.chem.tu-berlin.de: stephan owned process doing
 -bs
Date: Wed, 8 Jan 2003 17:39:59 +0100 (CET)
From: Stephan Michels <stephan@apache.org>
X-X-Sender: stephan@vern.chem.tu-berlin.de
To: cocoon-dev@xml.apache.org
Subject: RE: Defining Source  Interfaces
In-Reply-To: <LKENJPKDAIKAPKHEOCMMEEDFCEAA.cziegeler@s-und-n.de>
Message-ID: <Pine.LNX.4.44.0301081727580.14657-100000@vern.chem.tu-berlin.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N



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 copy a file,
> > >you can't hide all implementation details.
> > >
> > >
> >
> > Ah, I got it now : if the copied/moved source is of the same type than
> > the "source" source, then some optimisations are possible (like the
> > above or direct filesystem copy), else we fallback to a generic
> > getInputStream/getOutputStream implementation, right ?
> >
> > So it makes sense after all to keep them on the
> > [Modifiable/Writeable/Whatever]Source
> >
> No, I don't think so (sorry, I have to do this :) )
>
> 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 think we should add a "MoveableSource" (substitute the name if you
> like)

I thought these operations are a kind of writing operations.

> and have an utility class check if:
> a) both sources have the same implementation and
> b) implement MoveableSource
> If both is answered with yes, this can be used - if not the utility class
> uses IS/OS copying.

I like code sippets ;-)

class MySource implements MoveableSource
{
 void copy(Source source)
 {
   // impementation depending copy
 }
}

class SourceCopyUtil<whatever>
{
 void copy(Source from, Source to)
 {
   If ((from instanceof MoveableSource) &&
       (from.getClass().equals(to.getClass()))
    // impementation depending copy
    ((MoveableSource)from).copy(to);
   else
    IS/OS copy
 }
}

Something like that?

> It's the magic of SoC - if a source is not interested in move/copy it should
> not have to care about it.

Sometimes SoC is a pain, but I think the better way :-/

I also think that XMLizable isn't SoC, you should have to write
a (name)Serializer, which use \1.

Stephan


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org