Given that this is not going to affect the external APIs of Axis2 in any way, I think this is not an issue for 1.0. Do you guys agree?
Sanjiva. On Sat, 2006-04-08 at 13:42 +0600, Thilina Gunarathne wrote: > Hi Depak, > My apologies for the very late response.. I was planning to write a > detailed a response to your proposal, but wasn't able till now :(.. > > IMHO we need to do some internal tweekings of the mime parser in order > to achive the attachment streaming capability.. Currently we use Java > Mail to parse the content inside mime parts.. (content between the two > boundaries)..Our parser do the parsing up the boundaries.. AFAIK java > mail reads the whole MIME part whenever we create a MIMEPart... We'll > be returning an already read and buffered stream to the user If we go > ahead with this setup.. > > Inorder to give the user access to the pure attachments from the > instream, we need have the ability of deffrred parsing those MIMEparts > too... This basically means we need to improve our mime parser even to > parse the contents inside the MIMEParts too, so that we get the > capability to handle the stream in to Axis2.. Then we can just parse > the headers of the MIME part and wait at that point.. So that we can > return the real stream directly to the user when he requests it.. > > Did you addressed the above issue.. If so the perfomance will > definitely be improved.. > > ~Thilina > > On 4/8/06, Deepak Bhole <[EMAIL PROTECTED]> wrote: > > On Wed, 2006-04-05 at 15:46 -0400, Deepak Bhole wrote: > > > Hi, > > > > > > On Sat, 2006-03-25 at 00:38 -0800, Thilina Gunarathne wrote: > > > > Got ur point about the Attachment streaming support.. I can remember > > > > the earlier conversation too...Even though I thought of trying it out, > > > > unfortunately I wasn't able to do anything use full about it due to > > > > lack of time.. > > > > > > > > > > I am thinking of adding an IncomingAttachmentStreams object (same as > > > there was in axis1) which will serve as a container for streams. The > > > objects can then use getNextStream() on this object to access the MIME > > > streams. > > > > > > I am wondering if we need an IncomingAttachmentInputStream wrapper > > > object though. IncomingAttachmentStreams, while a stream for containers, > > > will have access to the Part objects directly (and the streams via > > > Part.getDataHandler().getDataSource().getInputStream()). In axis1, the > > > streams had an api which provided getContentType(), getContentId() etc. > > > functions. If there is no IncomingAttachmentInputStream wrapper, there > > > will simply be an InputStream stream, which won't provide those things. > > > I am for creating an IncomingAttachmentInputStream wrapper which will > > > provide those functions... > > > > > > > > being able to treat > > > > > MTOM/XOP messages just like SwA as well. > > > > I think we can do this in the inflow using the MIMEHelper.. I'm > > > > definitely +1 if we can replace it with a consistent API for both > > > > in/out flows. > > > > > > > > > > See above, IncomingAttachmentStreams will be contained inside > > > MIMEHelper, and thus can provide stream access. > > > > > > > >On the server-side say i get > > > > > a 1 MB attachment, don't want to put that into a data handler in > > > > > memory, i just want to stream it directly into whatever my application > > > > > specific wants > > > > Just a suggestion.. We can add another method to the OMText to get the > > > > stream directly.. Even in the current model the actual binary is read > > > > only when the user requests the data..(by calling getDataHandler() or > > > > getText() ). So it won't be hard to get the actual stream directly > > > > from there... > > > > > > > > > > The stream is within DataHandler, and not read until requested. Above > > > mentioned IncomingAttachmentStreams can take care of supplying that > > > stream.. > > > > > > > > OR if i am writing an intermediary i want to access all > > > > > the mime parts by myself > > > > IMO In the case of an intermediary we need to take special care with > > > > the content-id's.. If not the ultimate receiver will go in to trouble > > > > processing the mime parts. > > > > > > > > > > I am still getting to know axis2 .. could you please shed some light on > > > what you are referring to when you say intermediary? > > > > > > > >don't want Axis2 to do any MTOM related > > > > > processing. Please see Axis 1.X API [1] especially the > > > > > > > > Even at this moment Axis2 would create the OMText objects without data > > > > (only with a reference to the data) instead of XOP:Include elements. > > > > Other than this current Axis2 will not do any kind of MTOM specific > > > > processing of mime parts unless asked to do so.. > > > > > > > > > > right.. Base64 re-encoding is done in OMText::getText(), and thus not > > > done until requested (atleast afaik.. I might be off on this one) > > > > > > > > getIncomingAttachmentStreams method that allows direct access to the > > > > > mime parts. > > > > This would be a nice API for somebody who wants to do some low level > > > > processing. But we need to make sure to throw an Exception in the case > > > > a user trying to access them from both API's. If not Axiom will go > > > > nuts looking for the streams.. > > > > > > > > > > In the WIP implementation I have, I have it so that an > > > IllegalStateException is thrown (as in axis1) if the user attempts to > > > access the stream and the parts simultaneously. > > > > > > > *bump* > > > > Hi, > > > > The more I have been looking into this (all done actually, using the > > mechanism I stated above), the more I realize that it would be > > redundant. If the stream is always read only upon request (which it is) > > in the existing code, then providing a getNextStream() from an > > IncomingAttachmentsStream class provides no additional benefit in terms > > of performance. Should I finalize and post a patch on this anyway? Or is > > there a variation of this mechanism that someone would perhaps prefer? > > > > Thanks, > > Deepak > > > > > > > -- > "May the SourcE be with u" > http://webservices.apache.org/~thilina/ > http://thilinag.blogspot.com/ > http://www.bloglines.com/blog/Thilina
