----- Original Message ----- From: "Jim Lerner" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 30, 2003 12:10 Subject: Axis attachment naming enhancement (code attached)
> > The premise is simple: add a MIME header to each attachment with the > original filename. When the file is sent to Axis, Axis' > ManagedMemoryDataSource will use this name to create a uniquely named > temporary file (eg. Axis98765_myfile.xls) rather than the usual > (Axis98765axis). Likewise, when Axis receives a file to be sent back to > the caller, a MIME header on the attachment indicates the original name > (Axis98765_myfile.xls). This is not quite optimal, but it is easy > enough for the client to parse and use, given that the underscore is > guaranteed to be the first one in the filename. Existing applications > that don't set the MIME header will continue to see the previous file > naming behavior. I too have encountered this problem, which I fixed in my service API by making people add the filename, or at least the extension thereof as part of a separate array parameter. An ugly hack, but one which works across platforms, meaning .NET sending DIME messages still works. > > The changes that I've made (in the attached files) are as follows: First, we celebrate code enhancements, be we celebrate them more as CVS diffs, so it is easier to see what has changed and to merge those changes across versions. I should also add that AttachmentPart and some of the other files underwent mild change last weekend, to the extent that you can now ask an AttachmentPart for its filename (may be null), and detach the part from the filename so that when the AttachmentPart is finalized, the file that was uploaded is retained. That solved my more pressing problem, how to stop copying and leaking 30MB files, but also means that diffs against latest CVS are preferable. 1. I like the idea of sending some extra path information on attachments, though for security/privacy we'd need to be sure the caller wasnt leaking too much information. Should only the extension go? Or the filename+extension, ignoring the directories? I would prefer either of those to the full path. Of course, this is dependent on what DataSource.getName() implementationss return. 2. I also think that with the stuff that went in at the weekend, there is no need to save the received file with the original name (remember, we dont always save stuff), but could just make the mime header available to the recipient, who can get the file and rename it if they want. or save the in memory datastream to a file of the appropriate name too. 3. Interop worries me. If you code your server expecting this header, you cant handle any caller other than Axis. This doesnt mean we cant or shouldnt add the filename, just that it is dangerously non-standard, and the server cannot rely on it. Ugly explicit extra parameter hacks like what I used, may be the currently workable solution. I also dont like the way we are effectively forcing all files to disk before sending; that is not needed -but a consequence of calling getName(). [This is maybe a fault of ManagedMemoryDataSource.getName()] Overall then, I agree with you on the need to get some source file information, but I dont like the adverse consequences of this implementation: always saving files; having to add a new constructor to ManagedMemoryDataSource; a non-standard header leading to interop problems. The first is an implementation detail, the last more troublesome. I might bounce this past the soapbuilders, a little quirk on attachments, specifically the need to somehow retain a bit of file name info. But I dont think we need to put this in axis as it stands, yet. It can be done on a case by case basis in custom apps by -adding the header manually -getting the header manually -getting the current filename of the attachment and moving/renaming it. This adds extra dev work, but at least makes the interop issue explicit. If one web service does something automatically, people just assume it works everywhere. Thoughts? -Steve
