Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 66015 invoked by uid 500); 16 Jan 2003 18:08:44 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 65965 invoked from network); 16 Jan 2003 18:08:43 -0000 Message-ID: <000901c2bd8a$90c6a830$1219570f@ranier> From: "Steve Loughran" To: References: Subject: Re: cleanup of attachment files &c Date: Thu, 16 Jan 2003 10:10:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MailScanner: Found to be clean X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Rick Rineholt" To: 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.