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 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 ;-)
>
>
> sippets? :) (ok, just kidding)
>
>
>>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?
>>
>
> Exactly.
>
> Would you suggest to have two interfaces, one for copying
> and one for moving?
> Or is it ok, to implement a move as a copy/delete?
IMHO, no. Think of a 600MB file on your hardrive. When moving this file
from one folder to another it's much less expensive to play with the
I-Nodes, than actually copying 600MB of data and then deleting 600 MB of
data.
You should give the Source implementation a hook to do such
optimizations with a fallback of a default implementation.
Within a WebDAV repository, like Slide, you also loose all your
metadata, when not using the methods of the store for copying and moving
resources.
> Carsten
Jens
--
Jens Lorenz
interface:projects GmbH \\|//
Tolkewitzer Strasse 49 (o o)
01277 Dresden ~~~~oOOo~(_)~oOOo~~~~
Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
|