Hey Sanjiva:
On Fri, 2006-03-31 at 10:55 -0500, Davanum Srinivas wrote:
Let me try again...The DB framework will build the java objects
directly from the MIME root part (this is the first step always!) and
*then* accesses the other mime parts and sticks them where it is
needed (or adds a reference) on the java objects that it already
created. Except that OM tree is *never* built.
Ah but that's inconsistent with XOP .. if you do XOP, then when you look
at the XML at the Infoset level (which is what you do when you look at
the root part thru Axiom) then you have to un-XOPify it and just see the
XML Infoset. There's no halfway point.
Rrright, exactly. The point is that while what you just said is
perfectly true, you see the INFOSET (i.e. what you get out of
XmlStreamReader) but not necessarily the OM tree. So if a DB framework
like JIBX wants to handle the XOP support itself, it can do that by
doing something like this in the deserializer:
...deserializing from StAX events...
if (currentElement.getQName().equals(XOP_INCLUDE)) {
String contentID = getIDFromXopInclude();
XOPThing binaryThing =
new XOPThing(attachmentContext, contentID);
// insert binaryThing into the object we're deserializing
}
...continue...
XOPThing is this "future DataHandler" that we were talking about, maybe
just a DataHandler. But the point is it knows how to ask the
AttachmentContext object (with an API like what Dennis proposes) for the
actual InputStream and process it at the right time (obviously after all
the XML has been pulled/deserialized from the root part - when the
object tree is compete and the application asks for the image/data/etc).
As I'm thinking about it I wonder if we want to add a configuration
option which would automatically "pre-cache" all the attachments into
files immediately upon parsing the end of the root part, or if that
should indeed be the default behaviour. In other words, do we want to
support pausing the read on the actual HTTP InputStream until the
application asks for an attachment, much as we do with the SOAP envelope?
What you're looking at is SwA .. MTOM is not that IMO.
Same deal for either really, just in one case you have hrefs and in
another you have xop:Includes.
I guess we could put a flag saying "don't unXOPify" but that seems like
a hack.
You don't need a flag other than "don't cache" - which is really "don't
build the Object Model". If OM isn't building the Object Model, it
can't very well do unXOPification (where would it put anything?).
And on the sending
side, it generates stax events directly from the the java objects into
the MIME root part and adds the attachments into a bag while it is
doing so...again no OM tree in the picture at all.
+1 dims.
Again, you're thinking like SwA and not like a single unified Infoset
that has the binary parts logically in it. Think of WS-Security- how
will your model work with WS-Sec turned on to sign the whole shebang?
Great point. WS-Security (or anything else which requires the full
infoset to be preserved in the OM as well as the databound objects) will
need to switch on a flag which indicates "build the object model
always". So really, on the receiving side that flag should be an option
on the OM builder which overrides a call to
getXMLStreamReaderWithoutCaching() and turns it into a caching call.
This is transparent to both the security code (which wants an OM) and
the DB code (which wants StAX events) - both sides can get at the
attachments using the correct APIs. The optimization only works when no
one sets the "always build the OM" flag, but other than that it should
work transparently.
The same is true on the outbound side - if the flag is set, the StAX
events won't go directly out to the OutputStream representing the root
part of the MIME envelope (as they could in the optimized case), but
instead build up an OM so that a security (or checksum, or whatever)
handler can deal with it later.
Make sense?
--Glen
