axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: Attachments implementation: basic questions
Date Sat, 08 Sep 2001 00:13:57 GMT
Rob wrote:
>Hi, folks.  I may be able to scrounge some time in the next week or two to

work
>on Axis, and attachments seem to be the #1 task on the hit parade (that
isn't
>already being tackled by someone else).

COOL!

...
>So, my questions:
>- Are there any MIME libraries people know of that do "incremental"
parsing of
>the MIME body?  i.e. are there any MIME handlers that have a SAX-like
control
>flow?
>- I will obviously need to hook into Axis's HREF handling in order to
support
>attachments.  But it's a new case, in that previously to attachment
support
>Axis knew that any HREFs would reference only entities defined in the body
of
>the SOAP-ENV element.  Now, HREFs may reference entities in separate MIME
body
>parts, which may not even be reached until after the entire envelope's
parse
is
>complete.  So, does anyone foresee problems in HREF resolution if complete

HREF
>resolution must wait until the entire MIME envelope (not just the
SOAP-ENV)
has
>been parsed?  I suppose this question is really for Glen....
>- Would it be acceptable to do an interim implementation which assumes the

>whole message is read into memory?  Alternatively, would it be acceptable
to
do
>a "pre-pass" which parses the whole message into its elements (potentially

with
>hooks to allow disk persistence), then discards the original message
stream
and
>commences parsing the SOAP-ENV?  The latter seems the simplest, by far, as
it
>sidesteps the "not all HREFs available in the SOAP-ENV" issue I mentioned
above.
>Anyway, I suppose the "pre-pass" approach is what I will look at first.  I

will
>keep the list informed -- and I promise that if I do have to give up on
this
>prematurely, I will at least let everyone know.

It would be nice if the HREF was already read then it were resolved right
then.
And we would only keep reading ahead if we need to.  I'm not too keen on
the
idea of reading the whole thing into memory - in cases where the order of
the MIME stuff is:
   env
   attachment[s]
I see no reason to pre-parse or read the entire thing until someone
dereferences
the HREF that points to the attachment - or in other words, if no ever does
deference it then we should never have read/parsed it into memory.  If I
remember correctly, I believe one of the biggest worries of adding
attachment
support is it's impact on performance and I'm sure doing a preparse or
reading it all into memory(unless forced to) isn't going to help.

-Dug



Mime
View raw message