axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: cleanup of attachment files &c
Date Thu, 16 Jan 2003 18:10:32 GMT

----- Original Message -----
From: "Rick Rineholt" <rineholt@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Thursday, January 16, 2003 06:54
Subject: Re: cleanup of attachment files &c


> My 2 cents :  (Some of this -may- be close to what you are suggesting; it
> just  IMO over designed... but I know that is the Axis way)
>
> Create a disposal collection that will dispose all attachment resources
> after the service or call completes.  Should be in
>   a finally, statement.
>  Provide an interface to handlers and targeted services for both removing
> and adding attachments to  the disposal list.

I was thinking of a DisposalStrategy that gets passed down; strategies could
include
-do nothing
-attach to some disposal list
-mark for on close deletion

>
>  On the Server side automatically add all received attachments to the
> disposal list.

So we can assume that all attachments get associated with the current
context? What if the server is also creating a new outbound call? This
worries me: we need to choose the appropriate disposal strategy/list up
front

>  Provide mostly for the client the ability on the call/context to turn off
> the automatic disposal since there may be circumstances
>     where it may want more control and take charge of the disposal process
> and iterate over the list itself.

OK

>
> That's it.
>
> On the client side for the most part there is no real need for this since
> it can receive control after the call and can manage the attachment
> resources.
> On the server side for received attachments, if a fault occurs prior to
> the desired recipient receiving the attachment it will be deleted.

if we autodelete all non-preserved attachments, then deletion happens
regardless of faulting or not

> Once received it can be removed if it's desired to retain it.  On sending
> attachments if the resource is to be  deleted after it is sent the
> service can add it to the disposal list.
>
> In any case, provide  the opportunity to persist attachment resources with
> out the need to copy them.  I know already
> several users that envision sending and receiving giga byte sized
> attachments and prefer there NOT be the REQUIRED need to
> always copy them.


yeah, I am looking at 20-50+MB files. For that I may actually want to
control the location and name of attachments better, but could probably work
that out somehow. The key is to be able to remove items attachments from the
list, and to get the actual filename from an AttachmentPart.

What if each AttachmentPart knew about how it would be disposed, filename
and how to be removed from its disposal queue?

Whatever, this is becoming complex enough that it's a an axis1.2 kind of
feature.



Mime
View raw message