You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/11/18 05:35:30 UTC
[Axis2] IRC chat log 2004-11-17
we have talked about package structure (o.a.axis.core, o.a.axis2.*),
discussed OM goals
<http://wiki.apache.org/ws/FrontPage/Architecture/OMGoals> in particular
MTOM/XOP and how to do it (or not do it for now),
and related issues: data-binding, getObjectValue and DeserContext.
thanks,
alek
[11/17/2004 9:35 PM] =-= Topic for #apache-axis is ``Apache Axis web service framework WSDL SOAP XML-RPC''
[11/17/2004 9:35 PM] =-= Topic for #apache-axis was set by FR^2 on Monday, November 15, 2004 3:30:10 AM
[11/17/2004 9:35 PM] === #apache-axis [freenode-info] help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
[11/17/2004 9:50 PM] -->| Deepal (~deepal@220.247.253.222) has joined #apache-axis
[11/17/2004 9:55 PM] -->| Ajith (~Miranda@220.247.253.222) has joined #apache-axis
[11/17/2004 10:03 PM] -->| gdaniels (~gdaniels@psc.progress.com) has joined #apache-axis
[11/17/2004 10:03 PM] <gdaniels> hi all
[11/17/2004 10:06 PM] <Ajith> hi glen
[11/17/2004 10:06 PM] <Srinath> hi Glean :)
[11/17/2004 10:06 PM] <Srinath> we thought you wpuld be bit late ..
[11/17/2004 10:06 PM] <Ajith> we seem to be missing a lot today :D
[11/17/2004 10:06 PM] <gdaniels> I got out of rehearsal a little early
[11/17/2004 10:07 PM] <Srinath> :)
[11/17/2004 10:07 PM] <Deepal> hi all
[11/17/2004 10:07 PM] <Ajith> guitar ?
[11/17/2004 10:07 PM] <gdaniels> bass, yeah
[11/17/2004 10:07 PM] -->| farhaan (~Miranda@220.247.253.222) has joined #apache-axis
[11/17/2004 10:07 PM] <Ajith> whats on the agenda?
[11/17/2004 10:08 PM] <Deepal> its OM :(
[11/17/2004 10:08 PM] =-= YOU are now known as alek
[11/17/2004 10:08 PM] *NickServ* This nickname is owned by someone else
[11/17/2004 10:08 PM] *NickServ* If this is your nickname, type /msg NickServ IDENTIFY <password>
[11/17/2004 10:08 PM] =-= YOU are now known as alek_S
[11/17/2004 10:08 PM] <alek_S> agenda is in Wiki
[11/17/2004 10:08 PM] <Srinath> glen one Q , how about a package structure like org.apache.axis.core.engine
[11/17/2004 10:08 PM] <alek_S> http://wiki.apache.org/ws/ChatAgenda/20041117
[11/17/2004 10:08 PM] <gdaniels> Why :( ? Isn't OM fun? Don't we love OM?
[11/17/2004 10:08 PM] <Srinath> ..core.om
[11/17/2004 10:08 PM] <gdaniels> um...
[11/17/2004 10:09 PM] <Srinath> for the core of the engine
[11/17/2004 10:09 PM] <gdaniels> I don't so much like .core...
[11/17/2004 10:09 PM] <gdaniels> why would we do that?
[11/17/2004 10:09 PM] <alek_S> what is outside of core?
[11/17/2004 10:09 PM] <gdaniels> i.e. what would be in parallel with it?
[11/17/2004 10:09 PM] <Srinath> core have the internals ..
[11/17/2004 10:09 PM] =-= YOU are now known as alek_s
[11/17/2004 10:10 PM] <gdaniels> it might be harder than you think to separate the "internals" from the rest...
[11/17/2004 10:10 PM] <Srinath> glen:transport,providers ..
[11/17/2004 10:10 PM] <Srinath> handlers , encoding
[11/17/2004 10:10 PM] <Srinath> I check in a code just now .. if you can have a brif looka the structur
[11/17/2004 10:11 PM] <alek_s> the only way to ensure some leveld of conterol on interdependencies is to check during compilation
[11/17/2004 10:11 PM] <gdaniels> Hm. I think I prefer axis.engine, axis.om, axis.handlers... but will take a look
[11/17/2004 10:12 PM] -->| chathura (~chathura@220.247.222.249) has joined #apache-axis
[11/17/2004 10:12 PM] <Ajith> alek : what do you mean?
[11/17/2004 10:12 PM] <Srinath> thanks .. I love if we can seperate a core .. never mind which way:)
[11/17/2004 10:12 PM] <chathura> Hi all
[11/17/2004 10:12 PM] <alek_s> maybe to avoid confusion if soembody has old axis in classpath to use o.a.axis2.* ?
[11/17/2004 10:12 PM] <Ajith> Hi Chathura
[11/17/2004 10:13 PM] <gdaniels> alek: sure
[11/17/2004 10:14 PM] <gdaniels> So where is the current OM at?
[11/17/2004 10:14 PM] <Srinath> it is in chinthaka 's sractch am using jar
[11/17/2004 10:14 PM] <Srinath> should come as core.om I feel
[11/17/2004 10:15 PM] <gdaniels> See that feels weird to me especially in that we want om to be separable - feels odd to be able to pull things out from the core...
[11/17/2004 10:16 PM] <Srinath> yes .. but engine and om inseperable
[11/17/2004 10:16 PM] <gdaniels> No they aren't
[11/17/2004 10:16 PM] <gdaniels> You can use OM without the engine, right?
[11/17/2004 10:16 PM] -->| Chinthaka (~EC@220.247.222.249) has joined #apache-axis
[11/17/2004 10:16 PM] <Srinath> yes .. but engine can not live withouyt om
[11/17/2004 10:17 PM] <Chinthaka> hi all
[11/17/2004 10:17 PM] <Ajith> Om can live without the engine :)
[11/17/2004 10:17 PM] <Srinath> actually I trid hard to make poor engine stand alone but find no way :(
[11/17/2004 10:17 PM] <gdaniels> so fine, dependencies are all well and good, but I don't yet see why a "core" package makes sense
[11/17/2004 10:18 PM] <Ajith> hold on a sec. You say "engine" is dependent on OM?
[11/17/2004 10:18 PM] <gdaniels> I'm just wondering, should we be talking about OM? I think we can work out package stuff later...
[11/17/2004 10:18 PM] <alek_s> in other words what is outside of core?!
[11/17/2004 10:18 PM] <Ajith> I mean whay should it
[11/17/2004 10:18 PM] <Srinath> sure :)
[11/17/2004 10:18 PM] <Srinath> where are we at OM ?
[11/17/2004 10:19 PM] <gdaniels> So the OMAPI_with_Impl is the latest?
[11/17/2004 10:19 PM] <Ajith> I thought only the handlers are dependent on OM
[11/17/2004 10:19 PM] <Ajith> and the engine just picks a MC and passes it around
[11/17/2004 10:19 PM] <Srinath> I thin OM is latest :(
[11/17/2004 10:19 PM] <gdaniels> Ajith: I don't think even Handlers need to be dependent on OM
[11/17/2004 10:19 PM] <gdaniels> ...though the MC probably does
[11/17/2004 10:20 PM] <Srinath> MesgeCtx depend on OM .. that is the point
[11/17/2004 10:20 PM] <alek_s> i think trying to hide XML (and OM) from engine does nto make sense ...
[11/17/2004 10:20 PM] <Ajith> mmmm i see engine can stand without the Om but not the Handlers !
[11/17/2004 10:20 PM] <chathura> hmm i thought the handlers are gonna access the body through the Om
[11/17/2004 10:20 PM] <chathura> if at all
[11/17/2004 10:20 PM] <gdaniels> Ajith: +1
[11/17/2004 10:20 PM] <gdaniels> chathura: *particular* handlers might, but not the Handler infrastructure
[11/17/2004 10:21 PM] <Ajith> glen : i get you
[11/17/2004 10:21 PM] <gdaniels> OK, so some stuff I notice about the OM API as it stands...
[11/17/2004 10:21 PM] <gdaniels> It would be nice to have convenience funcs to get the first (or only) child element/attribute with a given QName without having to use an Iterator
[11/17/2004 10:22 PM] <gdaniels> public OMAttribute getAttributeByQName(QName qname)...
[11/17/2004 10:22 PM] <Ajith> you mean something like getChild(Qname) ?
[11/17/2004 10:22 PM] <alek_s> getElement
[11/17/2004 10:22 PM] <gdaniels> yes
[11/17/2004 10:22 PM] <Chinthaka> I put that iterator simply the QName can return more than one
[11/17/2004 10:23 PM] <alek_s> what are your thoughts about OM Goals
[11/17/2004 10:23 PM] <gdaniels> I know - and that's good, I'm just saying we should also have the "quick and easy" version
[11/17/2004 10:23 PM] <alek_s> (http://wiki.apache.org/ws/FrontPage/Architecture/OMGoals)
[11/17/2004 10:23 PM] <Chinthaka> glen : ok
[11/17/2004 10:23 PM] <gdaniels> alek: Reading...
[11/17/2004 10:23 PM] <Chinthaka> so this will return the first matching node !!
[11/17/2004 10:24 PM] <alek_s> i think we need to order the list of goals: and let fall things of the list that are not implemented/implementable now
[11/17/2004 10:24 PM] <gdaniels> Not sure about multiple implementations... that might be challenging
[11/17/2004 10:24 PM] <gdaniels> Chinthaka: yes
[11/17/2004 10:24 PM] <gdaniels> it's a good general goal, but I'm not sure it's a must-have
[11/17/2004 10:24 PM] <Chinthaka> glen : already we have two
[11/17/2004 10:24 PM] <alek_s> as long as API is not hardwired to impl that should be easy
[11/17/2004 10:24 PM] <gdaniels> ok
[11/17/2004 10:25 PM] <Srinath> but maintaining two might be tricky
[11/17/2004 10:25 PM] <gdaniels> I think our team should focus on one for now. :)
[11/17/2004 10:25 PM] <Srinath> yap :)
[11/17/2004 10:25 PM] <gdaniels> Otherwise, goals look pretty good to me, Alek!
[11/17/2004 10:25 PM] <Deepal> how can we select one
[11/17/2004 10:26 PM] <chathura> well i belive different impls can focus towards different types of xml doc sizes
[11/17/2004 10:26 PM] <Chinthaka> I have done some pef testing on two impls
[11/17/2004 10:26 PM] <gdaniels> I find it interesting that the serialization goal is accepted, but the "data binding" goal "needs more discussion"
[11/17/2004 10:26 PM] <alek_s> some of the goals are not currently realized in any impl
[11/17/2004 10:26 PM] <gdaniels> They're very related, I think
[11/17/2004 10:26 PM] <Deepal> both have diffrent level of perforemnce accoding to msg size
[11/17/2004 10:26 PM] <alek_s> foremost MTOM
[11/17/2004 10:26 PM] <gdaniels> Yup, MTOM and data binding APIs
[11/17/2004 10:27 PM] <Srinath> glen:serialization goal is OM->XML not Object->OM
[11/17/2004 10:27 PM] <gdaniels> It's also Object->OM
[11/17/2004 10:27 PM] <gdaniels> or Object->XML, really
[11/17/2004 10:27 PM] <alek_s> could we maybe work with Engine and figure ot what is needed to support streaming in and out of binary data into OM?
[11/17/2004 10:27 PM] <gdaniels> "AXIOM API makes possible to store Java objects convertible to XML Infoset on demand [for serialization]
[11/17/2004 10:27 PM] <Ajith> Glen : yeah that part we have to do
[11/17/2004 10:27 PM] <gdaniels> alek: I don't think you need the Engine for MTOM
[11/17/2004 10:28 PM] <alek_s> how do you propose to pass HTTP MIME attachments into OM?
[11/17/2004 10:28 PM] <gdaniels> You just need to be able to stream in a stream that's either a) raw XML or b) MIME
[11/17/2004 10:28 PM] <Srinath> but the code does the serializrion is Push code outside OM
[11/17/2004 10:29 PM] <gdaniels> the OMBuilder (or whatever) should have options to either force one way of doing it (and fail if it doesn't find what it's looking for), or auto-select based on the data stream itself
[11/17/2004 10:29 PM] <Chinthaka> alek : I out two MIME classes inside SOAPMessage to accomplish that
[11/17/2004 10:29 PM] <Ajith> glen : can we leave the MIME/MTOM thing for the first prototype
[11/17/2004 10:29 PM] <Chinthaka> sorry, I put :(
[11/17/2004 10:29 PM] <gdaniels> Srinath: Yes, but OM has to call out to the serialization infrastructure
[11/17/2004 10:29 PM] <Srinath> yes ..accepted :) ..
[11/17/2004 10:29 PM] <gdaniels> Ajith: Are you asking if we can do without it for the first prototype?
[11/17/2004 10:29 PM] <alek_s> Chinthaka: how will it work with Engine? in other words how one goes from MIME to OM?
[11/17/2004 10:30 PM] <Srinath> you are asking why not the same for data binding as well?
[11/17/2004 10:30 PM] <gdaniels> Srinath: I think the data binding code is actually very simple, and mostly relies on external SerializationContexts and DeserializationContexts
[11/17/2004 10:30 PM] <alek_s> Glen: OM needs to delegate to engine though some interface so it is possible in general way "optimize" MTOM enable infoset into transport (such as HTTP MIME)
[11/17/2004 10:30 PM] <Srinath> glen: you mean from the point of view of engine .. it is simple
[11/17/2004 10:31 PM] <gdaniels> alek: are you talking about serializing OM out to MIME/MTOM?
[11/17/2004 10:31 PM] <Ajith> glen : what i am suggesting is that we make the first prototype without MTOM!
[11/17/2004 10:32 PM] <Chinthaka> alek : I just left some flexibility for MIME in OM, but didn't look at how we can do that. Basically I got the idea from SAAJ
[11/17/2004 10:32 PM] <gdaniels> Ajith: Well we need the data binding APIs anyway, and the OM stuff is mostly under the covers
[11/17/2004 10:32 PM] <Ajith> hmmm
[11/17/2004 10:32 PM] <gdaniels> So if we have the getObjectValue()/setObjectValue() stuff I think we're good
[11/17/2004 10:33 PM] <alek_s> glen: yes - OM infoset with MTOM needs ot be serialized in transposrt specific way to acchieve "binary" optimizaiton
[11/17/2004 10:33 PM] <Chinthaka> can we use OM -> pull -> push -> databinding ?
[11/17/2004 10:33 PM] <alek_s> glen: how do you think shouls this happen?
[11/17/2004 10:33 PM] <Srinath> biggest problem I see om having the how to do data binding is to decided by provider
[11/17/2004 10:34 PM] <alek_s> Chinthaka: SAAJ API is specific to WSA and i think is a bit clumsy as it assumes MIME: MTOM works on Infoset level and should be very elegant and nicely integrated in OM IMHO
[11/17/2004 10:34 PM] <Ajith> BTW we can easily modify OM to have a binary thing (MTOM goes away after transport. right?)
[11/17/2004 10:34 PM] <gdaniels> alek: There should be an "OMSerializerContext" (or something) interface which knows how to write binary blobs and return IDs for them
[11/17/2004 10:34 PM] <alek_s> MTOM and XOP are hints in Infoset so transport needs to pick those "hints" somehow and do it in efficient ways
[11/17/2004 10:34 PM] <gdaniels> (so that we can write <xm:include...>
[11/17/2004 10:35 PM] <gdaniels> There was a proposal to do exactly this kind of thing for JAX-RPC/JAXB
[11/17/2004 10:35 PM] <alek_s> Glen: i agree there is need to pass soemhow information to engine that we need this part of infoset optimzied as binary
[11/17/2004 10:35 PM] <gdaniels> alek: Yes, but it's not "the engine" exactly, it's "the thing that implements OmSerContext"
[11/17/2004 10:36 PM] <alek_s> i have updated FrontPage/Architecture/OMGoals and marked MTOM that it needs more discussion and may not be impemented now
[11/17/2004 10:36 PM] <alek_s> engine will implemened OmSerContext right?
[11/17/2004 10:36 PM] <gdaniels> alek: Maybe :)
[11/17/2004 10:37 PM] <gdaniels> I don't think we need to answer that right now
[11/17/2004 10:37 PM] <gdaniels> We just need to know what is expected of the thing that's doing the OM writing
[11/17/2004 10:37 PM] <alek_s> how can we get to know this?
[11/17/2004 10:37 PM] <gdaniels> We write it! :)
[11/17/2004 10:38 PM] <alek_s> MTOM ?
[11/17/2004 10:38 PM] <alek_s> implement it?
[11/17/2004 10:38 PM] <gdaniels> Write the interface, I mean
[11/17/2004 10:38 PM] <alek_s> some use cases?
[11/17/2004 10:38 PM] <alek_s> what to put in this interface(s)?
[11/17/2004 10:38 PM] <gdaniels> We know it's got some API like "String writeBinary(byte[])"
[11/17/2004 10:39 PM] <gdaniels> or better yet
[11/17/2004 10:39 PM] <gdaniels> writeBinary(DataHandler)
[11/17/2004 10:39 PM] <alek_s> i agree somethign like that is needed
[11/17/2004 10:39 PM] <gdaniels> the String it returns is the CID, appropriate for inserting into an <xm:Include>
[11/17/2004 10:40 PM] <alek_s> i think it is very to add *efficient* impl of MTOM after engine and OM APIs are compelted and implemented?
[11/17/2004 10:40 PM] <gdaniels> s/very/very hard/ ?
[11/17/2004 10:40 PM] <alek_s> yes
[11/17/2004 10:40 PM] <alek_s> i would do it differently
[11/17/2004 10:40 PM] <Srinath> Ajith there was a Binary Node that discussesd .. is it rlevent to this om writing thing
[11/17/2004 10:40 PM] <Srinath> MTOM
[11/17/2004 10:40 PM] <gdaniels> maybe
[11/17/2004 10:41 PM] <gdaniels> How would you do it, Alek?
[11/17/2004 10:41 PM] <alek_s> i woudl store XmInlude as direct child of OmElement
[11/17/2004 10:41 PM] <alek_s> and let serializer figure out how to serialize XmlInclude
[11/17/2004 10:41 PM] <alek_s> if serialzier is provided with MTOM it goes as optimized MIME or whatever
[11/17/2004 10:41 PM] <gdaniels> Still have the same issues, though, just one level away. I was talking about the actual writer
[11/17/2004 10:41 PM] <alek_s> if it is not supporting MIME it writes BASE64
[11/17/2004 10:42 PM] <alek_s> this way Infoset API is consistent
[11/17/2004 10:42 PM] <alek_s> XmlInclude may just extend OmElement
[11/17/2004 10:42 PM] <gdaniels> Not sure I like a separate XmlInclude class...
[11/17/2004 10:43 PM] <Ajith> Srinath : well yeah. we had a binary node in mind
[11/17/2004 10:43 PM] <gdaniels> We've already got the notion that Objects might be hanging off OmElements
[11/17/2004 10:43 PM] <alek_s> i think it would be good to get few exampel of MTOM/XOP messages over HTTP/MIMR and write a simple example hot og generate them in OM ...
[11/17/2004 10:43 PM] <Ajith> a new node for the OM that stores a binary stream
[11/17/2004 10:43 PM] -->| dims (~dims@h00045ad8e984.ne.client2.attbi.com) has joined #apache-axis
[11/17/2004 10:43 PM] <gdaniels> hi dims
[11/17/2004 10:43 PM] <alek_s> hi dims
[11/17/2004 10:43 PM] <Srinath> hi dims
[11/17/2004 10:43 PM] <gdaniels> we're talking OM
[11/17/2004 10:43 PM] <alek_s> and MTOM
[11/17/2004 10:44 PM] <gdaniels> and data binding (oh my!)
[11/17/2004 10:44 PM] <alek_s> i think theremay be different kinds of binary content
[11/17/2004 10:44 PM] <Srinath> glen: there is a proposal for handler MTOM using a binary node in OM?
[11/17/2004 10:44 PM] <alek_s> streamed form files (backed by fiesystem), data bases or more (like DataHandler)
[11/17/2004 10:44 PM] <gdaniels> Srinath: s/handler/handling/ ?
[11/17/2004 10:44 PM] <Srinath> handle :)
[11/17/2004 10:45 PM] <alek_s> in ither words there is need for flexibility and multiple implementations of XmInclude
[11/17/2004 10:45 PM] <Srinath> Binary node like textnode .. that hold the Binary data.. and know how to read or write them
[11/17/2004 10:45 PM] <alek_s> which gets back to the point: how engine will pass and lifecycle streams in/out XmlInclude
[11/17/2004 10:46 PM] <alek_s> Srinath: yes
[11/17/2004 10:46 PM] <gdaniels> alek: Can DataHandlers be used to front files?
[11/17/2004 10:46 PM] <alek_s> Srinath: but it may not knwo how to write until engine/transport is accessed
[11/17/2004 10:46 PM] <gdaniels> i.e. can I make a DataHandler that will read a file when its contents are asked for
[11/17/2004 10:46 PM] <alek_s> glen: i think so (i would need to check it for 100%)
[11/17/2004 10:47 PM] <alek_s> still you need to stream incoming message attachments into files etc. - and this is done by engine right?
[11/17/2004 10:47 PM] <gdaniels> I think maybe yes also. If that's the case, why not just use DataHandlers for all binary content?
[11/17/2004 10:47 PM] <gdaniels> alek: it's done by someone
[11/17/2004 10:47 PM] <gdaniels> the OM would have the DataHandlers attached to it
[11/17/2004 10:47 PM] <alek_s> XmlInclude that knows all XOP seems better fit to support MTOM
[11/17/2004 10:48 PM] <alek_s> internally XmlInclude can use DataHandler?
[11/17/2004 10:48 PM] <Srinath> the binary node can hida a data handler ?
[11/17/2004 10:48 PM] <gdaniels> I'd like to see what you think the interface for XmlInclude looks like
[11/17/2004 10:48 PM] <gdaniels> I'm not seeing it yet, but maybe you could check in a proposal or send it to the list?
[11/17/2004 10:49 PM] <alek_s> there is lot of crap in DataHandler that is not needed in MTOM
[11/17/2004 10:49 PM] <alek_s> http://java.sun.com/products/javabeans/glasgow/javadocs/javax/activation/DataHandler.html
[11/17/2004 10:49 PM] <gdaniels> But DataHandler is the standard way to deal with MIME stuff and that's what we'll have
[11/17/2004 10:49 PM] <alek_s> XmlInclude would encapsulate exactly what is in XOM/MTOM ...
[11/17/2004 10:49 PM] <Ajith> IMHO xmlinclude seems to be another name for what we suggest as the OmBinaryNode
[11/17/2004 10:49 PM] <gdaniels> Ajith: And that's in one of the scratch areas already
[11/17/2004 10:49 PM] <gdaniels> ?
[11/17/2004 10:50 PM] <Chinthaka> ajith : yes
[11/17/2004 10:50 PM] <alek_s> and sure i think it should be implemented with DataHandler when needed
[11/17/2004 10:50 PM] <alek_s> Ajith: yes
[11/17/2004 10:51 PM] <Ajith> glen ; we dont have a binary node still in the implementations we have in the scratch. Do we Srinath?
[11/17/2004 10:51 PM] <alek_s> i think XopInclude should be consistent with Infoset defiend in XOP
[11/17/2004 10:51 PM] <alek_s> http://www.w3.org/TR/2004/NOTE-xopinc-FAQ-20040608/#q5
[11/17/2004 10:51 PM] <Chinthaka> Since, we *may* not implement MTOM for the time being, shall we focus a bit on data binding as well ??
[11/17/2004 10:52 PM] <Chinthaka> :(
[11/17/2004 10:52 PM] <alek_s> Chinthaka: that is the reason i have put goals so we can discuss it and make decision
[11/17/2004 10:52 PM] <alek_s> If we do not implement MTOM we do not need BinaryNodes
[11/17/2004 10:52 PM] <gdaniels> Chinthaka: I'd be happy to talk data binding
[11/17/2004 10:52 PM] <Chinthaka> glen : :)
[11/17/2004 10:53 PM] <alek_s> however that means that OM API may need to have drastical chnages in future
[11/17/2004 10:53 PM] <alek_s> including how binary data is handled througout engine ...
[11/17/2004 10:53 PM] <Srinath> let us add at least the interface Binary node to OM API
[11/17/2004 10:53 PM] <Srinath> may be implement ti later
[11/17/2004 10:53 PM] <gdaniels> As I see it, an OMElement is *either* going to have XML content (children/attributes) *or* Object content (a Java Object hanging off it)
[11/17/2004 10:53 PM] <alek_s> Srinath yes - i think as first step we can add XopInclude (OmBE) and have it impelment all infoset defined in XOP
[11/17/2004 10:54 PM] <gdaniels> If it's got Object content, and you write the element out, it calls out to a SerializationContext to do the work of pushing the XML events
[11/17/2004 10:54 PM] <Srinath> glen: Object contenet is set via a build that works on Object rather than a stream
[11/17/2004 10:54 PM] <alek_s> and for now have it serialized as BASE64 so it is "unoptimized" MTOM?!
[11/17/2004 10:54 PM] <Srinath> build=builder
[11/17/2004 10:54 PM] <gdaniels> Srinath: Or by just manually creating an OM hierarchy
[11/17/2004 10:55 PM] <Srinath> glen: we need differ creating OM As much as possible
[11/17/2004 10:55 PM] <alek_s> how such minimum MTOM without optimizations sound?
[11/17/2004 10:55 PM] <Srinath> at the reposne side as well ..
[11/17/2004 10:55 PM] <Chinthaka> I see in most of the data binding tools today SAX events are taken as inputs for unmarshalling
[11/17/2004 10:55 PM] <gdaniels> Chinthaka: We can gen SAX from pull events
[11/17/2004 10:56 PM] <Chinthaka> yeah
[11/17/2004 10:56 PM] <Srinath> if body not touched we write the object directly to out stream
[11/17/2004 10:56 PM] <gdaniels> Our deserializers will probably operate directly on pull
[11/17/2004 10:56 PM] <Chinthaka> so we can use existing OM API to do that
[11/17/2004 10:56 PM] <alek_s> also there is a related issue in goals: what is API to access SOAP:Body? see FrontPage/Architecture/OMGoals
[11/17/2004 10:56 PM] <Srinath> glen +1 for deserializers
[11/17/2004 10:56 PM] <gdaniels> Srinath: yup
[11/17/2004 10:56 PM] <Ajith> glen : yes so basically we provide pullevent (or pull wrapped in sax) to the external data binders
[11/17/2004 10:56 PM] <Ajith> is it?
[11/17/2004 10:56 PM] <gdaniels> Ajith: yes
[11/17/2004 10:57 PM] <Chinthaka> so thats gr8
[11/17/2004 10:57 PM] <gdaniels> and cache the object they return in the OMElement
[11/17/2004 10:57 PM] <alek_s> Ajith: you mean providing sax (push) wrapping pull stream?
[11/17/2004 10:57 PM] <Chinthaka> glen : didn't get u
[11/17/2004 10:57 PM] <Ajith> Alek : yeah
[11/17/2004 10:57 PM] <Chinthaka> alek : yes
[11/17/2004 10:57 PM] <gdaniels> Chinthaka: You've got an OMElement e;
[11/17/2004 10:57 PM] <Ajith> our OM is exposed to Daabinders through the pull warpper
[11/17/2004 10:57 PM] <gdaniels> You do "Object foo = e.getObjectValue();"
[11/17/2004 10:58 PM] <gdaniels> under the covers, the OM code calls out to a deserializer to translate the XML pull events into an Object
[11/17/2004 10:58 PM] <Srinath> glen: by keeping object chached inside a Builder we can avoid OM havig code for object specific code
[11/17/2004 10:58 PM] <gdaniels> the Object gets returned to you, and also cached in the OMElement
[11/17/2004 10:58 PM] <Ajith> the pull wrapper may be wrapped in a sax wrapper again depending on the need of the data binder
[11/17/2004 10:58 PM] <gdaniels> so next time you just get it instead of deserializing
[11/17/2004 10:58 PM] -->| dominik (~dominik@adsl-64-142-27-168.sonic.net) has joined #apache-axis
[11/17/2004 10:58 PM] <Srinath> it is builder that changed not OM element
[11/17/2004 10:58 PM] <gdaniels> Srinath: didn't get you?
[11/17/2004 10:58 PM] <Chinthaka> glen : what I thought was
[11/17/2004 10:59 PM] <Chinthaka> there is a Navigator sort of thing
[11/17/2004 10:59 PM] <Chinthaka> when you give an OMElement to that
[11/17/2004 10:59 PM] <gdaniels> Ajith: Yes
[11/17/2004 10:59 PM] <alek_s> glen: this gets back to issue ow to acccess SOAP:Body as stream
[11/17/2004 10:59 PM] <Chinthaka> u can get pull events from that Navigator
[11/17/2004 10:59 PM] <Srinath> glen: for each OM node there is a Builder .. OM node can reguest builder to proceed and build little bit more
[11/17/2004 10:59 PM] <alek_s> Navigator?
[11/17/2004 10:59 PM] <Srinath> glen: in the object case builder work on a object
[11/17/2004 11:00 PM] <Chinthaka> alek : yes, this will help to get pull evens
[11/17/2004 11:00 PM] <Chinthaka> to a given node
[11/17/2004 11:00 PM] <Srinath> glen: usual cse builder work on a pull parser
[11/17/2004 11:00 PM] <Chinthaka> so OM is not polluted with that code
[11/17/2004 11:01 PM] <gdaniels> Srinath: Right. So walk us through this? Pull parser pulls in XML and builds OM.
[11/17/2004 11:01 PM] <gdaniels> Let's say the whole OM got built
[11/17/2004 11:01 PM] <Ajith> on demand!
[11/17/2004 11:01 PM] <gdaniels> Let's assume someone asked for the whole structure, though, for now
[11/17/2004 11:01 PM] <gdaniels> So we've got the OMElements all the way down
[11/17/2004 11:01 PM] <Chinthaka> OMNode, will call the builder to proceed
[11/17/2004 11:01 PM] <gdaniels> (we'll do the stream case next)
[11/17/2004 11:02 PM] <Chinthaka> only if that element is not complete !!
[11/17/2004 11:02 PM] <gdaniels> ok
[11/17/2004 11:02 PM] <Ajith> then when the databinder needs it the navigator navigates the structure generating pull events
[11/17/2004 11:02 PM] <gdaniels> So now someone calls e.getObjectValue()
[11/17/2004 11:02 PM] <gdaniels> What happens?
[11/17/2004 11:03 PM] <Chinthaka> glen : can u tell me what do u expect from getObjectValue ?
[11/17/2004 11:03 PM] <alek_s> what is getObejctValue???
[11/17/2004 11:03 PM] <Chinthaka> did I miss something, earlier ? :(
[11/17/2004 11:03 PM] <gdaniels> The thingy that says "get me the deserialized value of this node"
[11/17/2004 11:03 PM] <alek_s> it returns *canonical* representation "eserialzied" of XML Infoset?
[11/17/2004 11:03 PM] <alek_s> tha is not possible
[11/17/2004 11:04 PM] <alek_s> there are many possible data bindinf representations for any XML infoset
[11/17/2004 11:04 PM] <gdaniels> Yes
[11/17/2004 11:04 PM] <alek_s> like xsd:date ...
[11/17/2004 11:04 PM] <gdaniels> That's why there's a DeserializationContext which knows how to do the actual work
[11/17/2004 11:04 PM] <alek_s> you can bind to Long, Date, XmlDate (in XmlBeans), etc.
[11/17/2004 11:04 PM] <alek_s> so you put DeserCtx in OM?
[11/17/2004 11:04 PM] <Ajith> nope
[11/17/2004 11:04 PM] <alek_s> or you pass it to OM when it needs it? getOV(ctx)?
[11/17/2004 11:04 PM] <Chinthaka> alek : I hope not
[11/17/2004 11:05 PM] <Ajith> here let me make this clear
[11/17/2004 11:05 PM] <gdaniels> alek: We didn't get that far when discussing at the F2F
[11/17/2004 11:05 PM] <Srinath> glen:pull parser pulls little bit more .. and if om sees it has not build enough he will ask builder to proceed bit more
[11/17/2004 11:05 PM] <gdaniels> I could see either
[11/17/2004 11:05 PM] <alek_s> i would liek OM to support very fexible data binding
[11/17/2004 11:05 PM] <alek_s> (hey see one of the goals: AXIOM API is designed to support data bindings and XML transformations and AXIOM API should work well with any data binding framework (XPath, XSLT, JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
[11/17/2004 11:05 PM] <Ajith> we have a dataBinder class that has bind method that retruns an array of objects and takes a pullparser wrapper
[11/17/2004 11:06 PM] <gdaniels> +1 for flexible data binding
[11/17/2004 11:06 PM] <Srinath> glen: that happens until om parse what ever requested (e.g. want to get all child elements)
[11/17/2004 11:06 PM] <Ajith> the engine calls the bind method with the pull parser
[11/17/2004 11:06 PM] <alek_s> i think there are many many ways that people want their XML served :)
[11/17/2004 11:06 PM] <alek_s> so maybe DeserCtx gets passed to builder?
[11/17/2004 11:07 PM] <alek_s> OMDocument builderImpl.parse(stream, deserCtx)?
[11/17/2004 11:07 PM] <gdaniels> I think we need to start building sample use cases to get this right
[11/17/2004 11:07 PM] <gdaniels> alek: That's certainly a good thought
[11/17/2004 11:07 PM] <alek_s> +1 to use cases !!!!
[11/17/2004 11:07 PM] <gdaniels> That's along the lines of what I was thinking back in Sri Lanka
[11/17/2004 11:08 PM] <gdaniels> but actual deserialization doesn't occur until something is asked for, just like pull doesn't happen until XML is asked for
[11/17/2004 11:09 PM] <alek_s> glen: that is good for efficiency so i am all for it
[11/17/2004 11:09 PM] <gdaniels> Ideally, I'd like to see data binding and MTOM support use the exact same APIs
[11/17/2004 11:09 PM] <gdaniels> They both represent getting some non-XML content (binary data or Java objects) from a certain place in the infoset
[11/17/2004 11:09 PM] <gdaniels> s/getting/getting or putting/
[11/17/2004 11:10 PM] <gdaniels> So the API lets you get or drop "stuff" at various places, and then the stuff behind the API (the Builders/Writers/Serializers/Deserializers) knows how to make that actually work
[11/17/2004 11:10 PM] <alek_s> still after all is said and done what we have is jsut XML Infoset
[11/17/2004 11:11 PM] <alek_s> just that we "optimize" or create "views" on XML Infoset
[11/17/2004 11:11 PM] <gdaniels> alek: Yes, and if you never use the "objecty" methods, you can treat it as infoset
[11/17/2004 11:11 PM] <gdaniels> yes yes
[11/17/2004 11:11 PM] <alek_s> so we can access it with Java Objects (data binding) or send it efficiently (MTOM that annotates XML Infoset)
[11/17/2004 11:11 PM] <gdaniels> :)
[11/17/2004 11:12 PM] <gdaniels> that's how I'm seeing it at the moment
[11/17/2004 11:12 PM] <alek_s> it seems that finally people see value in XML and do nto try to use it as RPC transfer ...
[11/17/2004 11:12 PM] <gdaniels> stop dissing RPC, buddy.
[11/17/2004 11:12 PM] <gdaniels> :)
[11/17/2004 11:12 PM] <gdaniels> THERE IS NOTHING WRONG WITH RPCs IN THE RIGHT CASES! (dammit)
[11/17/2004 11:13 PM] <alek_s> i like RPC i wrote RMI impl - check SoapRMI ...
[11/17/2004 11:13 PM] <gdaniels> I know. :) I just figured you'd converted entirely.
[11/17/2004 11:13 PM] <alek_s> though still there is impedance mismatch if you try to do RPC and XML documents messaging ...
[11/17/2004 11:13 PM] <gdaniels> We're still going to support RPCs, and that will likely be an early use case...
[11/17/2004 11:13 PM] <alek_s> i have different angle: now all is XML Infoset :) new religion :)
[11/17/2004 11:14 PM] <gdaniels> Well, good luck writing your programming language that has elements and attributes as native data types...
[11/17/2004 11:14 PM] <gdaniels> Oh wait that's XQuery... :)
[11/17/2004 11:14 PM] <alek_s> and i am fine if somebody want to generate all XML Infoset from RPC - "not that there is anything wrong with that"
[11/17/2004 11:15 PM] <alek_s> haha
[11/17/2004 11:15 PM] <gdaniels> So others, any commentary on all that?
[11/17/2004 11:15 PM] <Ajith> on RPC ? :)
[11/17/2004 11:16 PM] <gdaniels> no, the infoset/MTOM/data binding stuff... :)
[11/17/2004 11:16 PM] <alek_s> anybody: any thoughts about FrontPage/Architecture/OMGoals
[11/17/2004 11:16 PM] <alek_s> something is not clear? missing? should be added?
[11/17/2004 11:16 PM] <Chinthaka> alek : a suggestion !!
[11/17/2004 11:16 PM] <alek_s> re-prioritized?
[11/17/2004 11:16 PM] <Srinath> :) om seem to be tricker tha I thought ;)
[11/17/2004 11:16 PM] <alek_s> go ahead
[11/17/2004 11:17 PM] <Chinthaka> shall we put all the wiki pages in one place
[11/17/2004 11:17 PM] <Ajith> seems quite complete but I might make some changes later
[11/17/2004 11:17 PM] <alek_s> Srinath: if we get it right OM becomes strong backbone of AXIS2, if not ...
[11/17/2004 11:17 PM] <Chinthaka> and extract all the need information and re-create the pages
[11/17/2004 11:17 PM] <alek_s> Ajith: please do - it is great if OMGoals is live document
[11/17/2004 11:17 PM] <gdaniels> alek: If we get it right OM becomes an API that a lot of other projects want to steal from Axis2...
[11/17/2004 11:18 PM] <Chinthaka> glen : wow, boosting moral !!!
[11/17/2004 11:18 PM] <Chinthaka> ;)
[11/17/2004 11:18 PM] <gdaniels> Well, it's a big "if" :)
[11/17/2004 11:18 PM] <alek_s> we are like cooking - we got ingredients (goals, reqs, prototypes) and we put them in OM - hopefully we get soemthing worth stealing :-)
[11/17/2004 11:18 PM] <Srinath> :)
[11/17/2004 11:18 PM] <Chinthaka> :D
[11/17/2004 11:19 PM] <alek_s> stealing is sure notion that project is succesulf ;->
[11/17/2004 11:19 PM] <gdaniels> Anybody know how big/fast JDOM is these days, by the way?
[11/17/2004 11:19 PM] <alek_s> JDOM is very big - it is unvbelivable how many methods are there ...
[11/17/2004 11:19 PM] <Srinath> unfurtunatly they can not steel it since everything is open ;)
[11/17/2004 11:19 PM] <Srinath> unfourtunatly
[11/17/2004 11:19 PM] <alek_s> steal in good sense, "extended" sharing and reuse
[11/17/2004 11:19 PM] <gdaniels> Srinath: Picky, picky. :) "use" then...
[11/17/2004 11:19 PM] <Chinthaka> I did a OM comparison with JDOM
[11/17/2004 11:20 PM] <Srinath> :D
[11/17/2004 11:20 PM] <Chinthaka> seems like OM Linked List impl is faster than JDOM !!
[11/17/2004 11:20 PM] <Chinthaka> seems like cooking seems fine ;)
[11/17/2004 11:21 PM] <gdaniels> ok, I think I'm going to head to bed now, folks.
[11/17/2004 11:21 PM] <alek_s> i think we got more ro less covered from ChatAgenda? http://wiki.apache.org/ws/ChatAgenda_2f20041117#preview
[11/17/2004 11:21 PM] <gdaniels> I'll try to write up some of the databinding/mtom stuff around the current OM proposals
[11/17/2004 11:22 PM] <Srinath> bye glen .. will try to get that Binary node up ..
[11/17/2004 11:22 PM] <alek_s> i think we gettign close to actually maybe understand what it takes in APU to do MTOM and data-binding ...
[11/17/2004 11:22 PM] <gdaniels> alek: I think so too, now we just need to see it in code.
[11/17/2004 11:23 PM] <gdaniels> alek: You going to send the log?
[11/17/2004 11:25 PM] <Srinath> are we done :)
[11/17/2004 11:25 PM] <gdaniels> think so... :) Alek, if you don't send the log tonight I'll do it tomorrow.
[11/17/2004 11:25 PM] <gdaniels> Good night folks!
[11/17/2004 11:25 PM] <Chinthaka> good night, sweet OM Dreams !!
[11/17/2004 11:25 PM] <alek_s> i will send logs
[11/17/2004 11:26 PM] |<-- gdaniels has left irc.freenode.net ()
[11/17/2004 11:26 PM] <alek_s> good night/morning everybody!
[11/17/2004 11:26 PM] <Srinath> bye all
[11/17/2004 11:26 PM] <alek_s> bye
[11/17/2004 11:26 PM] <--| farhaan has left #apache-axis
[11/17/2004 11:26 PM] |<-- Srinath has left irc.freenode.net ("Client Exiting")
[11/17/2004 11:26 PM] <--| Deepal has left #apache-axis
[11/17/2004 11:26 PM] |<-- chathura has left irc.freenode.net ()
[11/17/2004 11:26 PM] |<-- Chinthaka has left irc.freenode.net ("Leaving")
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] IRC chat log 2004-11-17
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Sorry for going MIA yesterday .. I'm at ICSOC '04 and have been
swamped. Will be home next week ....
Sanjiva.
----- Original Message -----
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ax...@ws.apache.org>
Sent: Thursday, November 18, 2004 10:35 AM
Subject: [Axis2] IRC chat log 2004-11-17
> we have talked about package structure (o.a.axis.core, o.a.axis2.*),
> discussed OM goals
> <http://wiki.apache.org/ws/FrontPage/Architecture/OMGoals> in particular
> MTOM/XOP and how to do it (or not do it for now),
> and related issues: data-binding, getObjectValue and DeserContext.
>
> thanks,
>
> alek
>
> [11/17/2004 9:35 PM] =-= Topic for #apache-axis is ``Apache Axis web
service framework WSDL SOAP XML-RPC''
> [11/17/2004 9:35 PM] =-= Topic for #apache-axis was set by FR^2 on Monday,
November 15, 2004 3:30:10 AM
> [11/17/2004 9:35 PM] === #apache-axis [freenode-info] help freenode weed
out clonebots, please register your IRC nick and auto-identify:
http://freenode.net/faq.shtml#nicksetup
> [11/17/2004 9:50 PM] -->| Deepal (~deepal@220.247.253.222) has joined
#apache-axis
> [11/17/2004 9:55 PM] -->| Ajith (~Miranda@220.247.253.222) has joined
#apache-axis
> [11/17/2004 10:03 PM] -->| gdaniels (~gdaniels@psc.progress.com) has
joined #apache-axis
> [11/17/2004 10:03 PM] <gdaniels> hi all
> [11/17/2004 10:06 PM] <Ajith> hi glen
> [11/17/2004 10:06 PM] <Srinath> hi Glean :)
> [11/17/2004 10:06 PM] <Srinath> we thought you wpuld be bit late ..
> [11/17/2004 10:06 PM] <Ajith> we seem to be missing a lot today :D
> [11/17/2004 10:06 PM] <gdaniels> I got out of rehearsal a little early
> [11/17/2004 10:07 PM] <Srinath> :)
> [11/17/2004 10:07 PM] <Deepal> hi all
> [11/17/2004 10:07 PM] <Ajith> guitar ?
> [11/17/2004 10:07 PM] <gdaniels> bass, yeah
> [11/17/2004 10:07 PM] -->| farhaan (~Miranda@220.247.253.222) has joined
#apache-axis
> [11/17/2004 10:07 PM] <Ajith> whats on the agenda?
> [11/17/2004 10:08 PM] <Deepal> its OM :(
> [11/17/2004 10:08 PM] =-= YOU are now known as alek
> [11/17/2004 10:08 PM] *NickServ* This nickname is owned by someone else
> [11/17/2004 10:08 PM] *NickServ* If this is your nickname, type /msg
NickServ IDENTIFY <password>
> [11/17/2004 10:08 PM] =-= YOU are now known as alek_S
> [11/17/2004 10:08 PM] <alek_S> agenda is in Wiki
> [11/17/2004 10:08 PM] <Srinath> glen one Q , how about a package
structure like org.apache.axis.core.engine
> [11/17/2004 10:08 PM] <alek_S>
http://wiki.apache.org/ws/ChatAgenda/20041117
> [11/17/2004 10:08 PM] <gdaniels> Why :( ? Isn't OM fun? Don't we love OM?
> [11/17/2004 10:08 PM] <Srinath> ..core.om
> [11/17/2004 10:08 PM] <gdaniels> um...
> [11/17/2004 10:09 PM] <Srinath> for the core of the engine
> [11/17/2004 10:09 PM] <gdaniels> I don't so much like .core...
> [11/17/2004 10:09 PM] <gdaniels> why would we do that?
> [11/17/2004 10:09 PM] <alek_S> what is outside of core?
> [11/17/2004 10:09 PM] <gdaniels> i.e. what would be in parallel with it?
> [11/17/2004 10:09 PM] <Srinath> core have the internals ..
> [11/17/2004 10:09 PM] =-= YOU are now known as alek_s
> [11/17/2004 10:10 PM] <gdaniels> it might be harder than you think to
separate the "internals" from the rest...
> [11/17/2004 10:10 PM] <Srinath> glen:transport,providers ..
> [11/17/2004 10:10 PM] <Srinath> handlers , encoding
> [11/17/2004 10:10 PM] <Srinath> I check in a code just now .. if you can
have a brif looka the structur
> [11/17/2004 10:11 PM] <alek_s> the only way to ensure some leveld of
conterol on interdependencies is to check during compilation
> [11/17/2004 10:11 PM] <gdaniels> Hm. I think I prefer axis.engine,
axis.om, axis.handlers... but will take a look
> [11/17/2004 10:12 PM] -->| chathura (~chathura@220.247.222.249) has joined
#apache-axis
> [11/17/2004 10:12 PM] <Ajith> alek : what do you mean?
> [11/17/2004 10:12 PM] <Srinath> thanks .. I love if we can seperate a core
.. never mind which way:)
> [11/17/2004 10:12 PM] <chathura> Hi all
> [11/17/2004 10:12 PM] <alek_s> maybe to avoid confusion if soembody has
old axis in classpath to use o.a.axis2.* ?
> [11/17/2004 10:12 PM] <Ajith> Hi Chathura
> [11/17/2004 10:13 PM] <gdaniels> alek: sure
> [11/17/2004 10:14 PM] <gdaniels> So where is the current OM at?
> [11/17/2004 10:14 PM] <Srinath> it is in chinthaka 's sractch am using jar
> [11/17/2004 10:14 PM] <Srinath> should come as core.om I feel
> [11/17/2004 10:15 PM] <gdaniels> See that feels weird to me especially in
that we want om to be separable - feels odd to be able to pull things out
from the core...
> [11/17/2004 10:16 PM] <Srinath> yes .. but engine and om inseperable
> [11/17/2004 10:16 PM] <gdaniels> No they aren't
> [11/17/2004 10:16 PM] <gdaniels> You can use OM without the engine, right?
> [11/17/2004 10:16 PM] -->| Chinthaka (~EC@220.247.222.249) has joined
#apache-axis
> [11/17/2004 10:16 PM] <Srinath> yes .. but engine can not live withouyt om
> [11/17/2004 10:17 PM] <Chinthaka> hi all
> [11/17/2004 10:17 PM] <Ajith> Om can live without the engine :)
> [11/17/2004 10:17 PM] <Srinath> actually I trid hard to make poor engine
stand alone but find no way :(
> [11/17/2004 10:17 PM] <gdaniels> so fine, dependencies are all well and
good, but I don't yet see why a "core" package makes sense
> [11/17/2004 10:18 PM] <Ajith> hold on a sec. You say "engine" is dependent
on OM?
> [11/17/2004 10:18 PM] <gdaniels> I'm just wondering, should we be talking
about OM? I think we can work out package stuff later...
> [11/17/2004 10:18 PM] <alek_s> in other words what is outside of core?!
> [11/17/2004 10:18 PM] <Ajith> I mean whay should it
> [11/17/2004 10:18 PM] <Srinath> sure :)
> [11/17/2004 10:18 PM] <Srinath> where are we at OM ?
> [11/17/2004 10:19 PM] <gdaniels> So the OMAPI_with_Impl is the latest?
> [11/17/2004 10:19 PM] <Ajith> I thought only the handlers are dependent on
OM
> [11/17/2004 10:19 PM] <Ajith> and the engine just picks a MC and passes it
around
> [11/17/2004 10:19 PM] <Srinath> I thin OM is latest :(
> [11/17/2004 10:19 PM] <gdaniels> Ajith: I don't think even Handlers need
to be dependent on OM
> [11/17/2004 10:19 PM] <gdaniels> ...though the MC probably does
> [11/17/2004 10:20 PM] <Srinath> MesgeCtx depend on OM .. that is the point
> [11/17/2004 10:20 PM] <alek_s> i think trying to hide XML (and OM) from
engine does nto make sense ...
> [11/17/2004 10:20 PM] <Ajith> mmmm i see engine can stand without the Om
but not the Handlers !
> [11/17/2004 10:20 PM] <chathura> hmm i thought the handlers are gonna
access the body through the Om
> [11/17/2004 10:20 PM] <chathura> if at all
> [11/17/2004 10:20 PM] <gdaniels> Ajith: +1
> [11/17/2004 10:20 PM] <gdaniels> chathura: *particular* handlers might,
but not the Handler infrastructure
> [11/17/2004 10:21 PM] <Ajith> glen : i get you
> [11/17/2004 10:21 PM] <gdaniels> OK, so some stuff I notice about the OM
API as it stands...
> [11/17/2004 10:21 PM] <gdaniels> It would be nice to have convenience
funcs to get the first (or only) child element/attribute with a given QName
without having to use an Iterator
> [11/17/2004 10:22 PM] <gdaniels> public OMAttribute
getAttributeByQName(QName qname)...
> [11/17/2004 10:22 PM] <Ajith> you mean something like getChild(Qname) ?
> [11/17/2004 10:22 PM] <alek_s> getElement
> [11/17/2004 10:22 PM] <gdaniels> yes
> [11/17/2004 10:22 PM] <Chinthaka> I put that iterator simply the QName can
return more than one
> [11/17/2004 10:23 PM] <alek_s> what are your thoughts about OM Goals
> [11/17/2004 10:23 PM] <gdaniels> I know - and that's good, I'm just saying
we should also have the "quick and easy" version
> [11/17/2004 10:23 PM] <alek_s>
(http://wiki.apache.org/ws/FrontPage/Architecture/OMGoals)
> [11/17/2004 10:23 PM] <Chinthaka> glen : ok
> [11/17/2004 10:23 PM] <gdaniels> alek: Reading...
> [11/17/2004 10:23 PM] <Chinthaka> so this will return the first matching
node !!
> [11/17/2004 10:24 PM] <alek_s> i think we need to order the list of goals:
and let fall things of the list that are not implemented/implementable now
> [11/17/2004 10:24 PM] <gdaniels> Not sure about multiple
implementations... that might be challenging
> [11/17/2004 10:24 PM] <gdaniels> Chinthaka: yes
> [11/17/2004 10:24 PM] <gdaniels> it's a good general goal, but I'm not
sure it's a must-have
> [11/17/2004 10:24 PM] <Chinthaka> glen : already we have two
> [11/17/2004 10:24 PM] <alek_s> as long as API is not hardwired to impl
that should be easy
> [11/17/2004 10:24 PM] <gdaniels> ok
> [11/17/2004 10:25 PM] <Srinath> but maintaining two might be tricky
> [11/17/2004 10:25 PM] <gdaniels> I think our team should focus on one for
now. :)
> [11/17/2004 10:25 PM] <Srinath> yap :)
> [11/17/2004 10:25 PM] <gdaniels> Otherwise, goals look pretty good to me,
Alek!
> [11/17/2004 10:25 PM] <Deepal> how can we select one
> [11/17/2004 10:26 PM] <chathura> well i belive different impls can focus
towards different types of xml doc sizes
> [11/17/2004 10:26 PM] <Chinthaka> I have done some pef testing on two
impls
> [11/17/2004 10:26 PM] <gdaniels> I find it interesting that the
serialization goal is accepted, but the "data binding" goal "needs more
discussion"
> [11/17/2004 10:26 PM] <alek_s> some of the goals are not currently
realized in any impl
> [11/17/2004 10:26 PM] <gdaniels> They're very related, I think
> [11/17/2004 10:26 PM] <Deepal> both have diffrent level of perforemnce
accoding to msg size
> [11/17/2004 10:26 PM] <alek_s> foremost MTOM
> [11/17/2004 10:26 PM] <gdaniels> Yup, MTOM and data binding APIs
> [11/17/2004 10:27 PM] <Srinath> glen:serialization goal is OM->XML not
Object->OM
> [11/17/2004 10:27 PM] <gdaniels> It's also Object->OM
> [11/17/2004 10:27 PM] <gdaniels> or Object->XML, really
> [11/17/2004 10:27 PM] <alek_s> could we maybe work with Engine and figure
ot what is needed to support streaming in and out of binary data into OM?
> [11/17/2004 10:27 PM] <gdaniels> "AXIOM API makes possible to store Java
objects convertible to XML Infoset on demand [for serialization]
> [11/17/2004 10:27 PM] <Ajith> Glen : yeah that part we have to do
> [11/17/2004 10:27 PM] <gdaniels> alek: I don't think you need the Engine
for MTOM
> [11/17/2004 10:28 PM] <alek_s> how do you propose to pass HTTP MIME
attachments into OM?
> [11/17/2004 10:28 PM] <gdaniels> You just need to be able to stream in a
stream that's either a) raw XML or b) MIME
> [11/17/2004 10:28 PM] <Srinath> but the code does the serializrion is Push
code outside OM
> [11/17/2004 10:29 PM] <gdaniels> the OMBuilder (or whatever) should have
options to either force one way of doing it (and fail if it doesn't find
what it's looking for), or auto-select based on the data stream itself
> [11/17/2004 10:29 PM] <Chinthaka> alek : I out two MIME classes inside
SOAPMessage to accomplish that
> [11/17/2004 10:29 PM] <Ajith> glen : can we leave the MIME/MTOM thing for
the first prototype
> [11/17/2004 10:29 PM] <Chinthaka> sorry, I put :(
> [11/17/2004 10:29 PM] <gdaniels> Srinath: Yes, but OM has to call out to
the serialization infrastructure
> [11/17/2004 10:29 PM] <Srinath> yes ..accepted :) ..
> [11/17/2004 10:29 PM] <gdaniels> Ajith: Are you asking if we can do
without it for the first prototype?
> [11/17/2004 10:29 PM] <alek_s> Chinthaka: how will it work with Engine? in
other words how one goes from MIME to OM?
> [11/17/2004 10:30 PM] <Srinath> you are asking why not the same for data
binding as well?
> [11/17/2004 10:30 PM] <gdaniels> Srinath: I think the data binding code is
actually very simple, and mostly relies on external SerializationContexts
and DeserializationContexts
> [11/17/2004 10:30 PM] <alek_s> Glen: OM needs to delegate to engine though
some interface so it is possible in general way "optimize" MTOM enable
infoset into transport (such as HTTP MIME)
> [11/17/2004 10:30 PM] <Srinath> glen: you mean from the point of view of
engine .. it is simple
> [11/17/2004 10:31 PM] <gdaniels> alek: are you talking about serializing
OM out to MIME/MTOM?
> [11/17/2004 10:31 PM] <Ajith> glen : what i am suggesting is that we make
the first prototype without MTOM!
> [11/17/2004 10:32 PM] <Chinthaka> alek : I just left some flexibility for
MIME in OM, but didn't look at how we can do that. Basically I got the idea
from SAAJ
> [11/17/2004 10:32 PM] <gdaniels> Ajith: Well we need the data binding APIs
anyway, and the OM stuff is mostly under the covers
> [11/17/2004 10:32 PM] <Ajith> hmmm
> [11/17/2004 10:32 PM] <gdaniels> So if we have the
getObjectValue()/setObjectValue() stuff I think we're good
> [11/17/2004 10:33 PM] <alek_s> glen: yes - OM infoset with MTOM needs ot
be serialized in transposrt specific way to acchieve "binary" optimizaiton
> [11/17/2004 10:33 PM] <Chinthaka> can we use OM -> pull -> push ->
databinding ?
> [11/17/2004 10:33 PM] <alek_s> glen: how do you think shouls this happen?
> [11/17/2004 10:33 PM] <Srinath> biggest problem I see om having the how to
do data binding is to decided by provider
> [11/17/2004 10:34 PM] <alek_s> Chinthaka: SAAJ API is specific to WSA and
i think is a bit clumsy as it assumes MIME: MTOM works on Infoset level and
should be very elegant and nicely integrated in OM IMHO
> [11/17/2004 10:34 PM] <Ajith> BTW we can easily modify OM to have a binary
thing (MTOM goes away after transport. right?)
> [11/17/2004 10:34 PM] <gdaniels> alek: There should be an
"OMSerializerContext" (or something) interface which knows how to write
binary blobs and return IDs for them
> [11/17/2004 10:34 PM] <alek_s> MTOM and XOP are hints in Infoset so
transport needs to pick those "hints" somehow and do it in efficient ways
> [11/17/2004 10:34 PM] <gdaniels> (so that we can write <xm:include...>
> [11/17/2004 10:35 PM] <gdaniels> There was a proposal to do exactly this
kind of thing for JAX-RPC/JAXB
> [11/17/2004 10:35 PM] <alek_s> Glen: i agree there is need to pass soemhow
information to engine that we need this part of infoset optimzied as binary
> [11/17/2004 10:35 PM] <gdaniels> alek: Yes, but it's not "the engine"
exactly, it's "the thing that implements OmSerContext"
> [11/17/2004 10:36 PM] <alek_s> i have updated
FrontPage/Architecture/OMGoals and marked MTOM that it needs more
discussion and may not be impemented now
> [11/17/2004 10:36 PM] <alek_s> engine will implemened OmSerContext right?
> [11/17/2004 10:36 PM] <gdaniels> alek: Maybe :)
> [11/17/2004 10:37 PM] <gdaniels> I don't think we need to answer that
right now
> [11/17/2004 10:37 PM] <gdaniels> We just need to know what is expected of
the thing that's doing the OM writing
> [11/17/2004 10:37 PM] <alek_s> how can we get to know this?
> [11/17/2004 10:37 PM] <gdaniels> We write it! :)
> [11/17/2004 10:38 PM] <alek_s> MTOM ?
> [11/17/2004 10:38 PM] <alek_s> implement it?
> [11/17/2004 10:38 PM] <gdaniels> Write the interface, I mean
> [11/17/2004 10:38 PM] <alek_s> some use cases?
> [11/17/2004 10:38 PM] <alek_s> what to put in this interface(s)?
> [11/17/2004 10:38 PM] <gdaniels> We know it's got some API like "String
writeBinary(byte[])"
> [11/17/2004 10:39 PM] <gdaniels> or better yet
> [11/17/2004 10:39 PM] <gdaniels> writeBinary(DataHandler)
> [11/17/2004 10:39 PM] <alek_s> i agree somethign like that is needed
> [11/17/2004 10:39 PM] <gdaniels> the String it returns is the CID,
appropriate for inserting into an <xm:Include>
> [11/17/2004 10:40 PM] <alek_s> i think it is very to add *efficient* impl
of MTOM after engine and OM APIs are compelted and implemented?
> [11/17/2004 10:40 PM] <gdaniels> s/very/very hard/ ?
> [11/17/2004 10:40 PM] <alek_s> yes
> [11/17/2004 10:40 PM] <alek_s> i would do it differently
> [11/17/2004 10:40 PM] <Srinath> Ajith there was a Binary Node that
discussesd .. is it rlevent to this om writing thing
> [11/17/2004 10:40 PM] <Srinath> MTOM
> [11/17/2004 10:40 PM] <gdaniels> maybe
> [11/17/2004 10:41 PM] <gdaniels> How would you do it, Alek?
> [11/17/2004 10:41 PM] <alek_s> i woudl store XmInlude as direct child of
OmElement
> [11/17/2004 10:41 PM] <alek_s> and let serializer figure out how to
serialize XmlInclude
> [11/17/2004 10:41 PM] <alek_s> if serialzier is provided with MTOM it goes
as optimized MIME or whatever
> [11/17/2004 10:41 PM] <gdaniels> Still have the same issues, though, just
one level away. I was talking about the actual writer
> [11/17/2004 10:41 PM] <alek_s> if it is not supporting MIME it writes
BASE64
> [11/17/2004 10:42 PM] <alek_s> this way Infoset API is consistent
> [11/17/2004 10:42 PM] <alek_s> XmlInclude may just extend OmElement
> [11/17/2004 10:42 PM] <gdaniels> Not sure I like a separate XmlInclude
class...
> [11/17/2004 10:43 PM] <Ajith> Srinath : well yeah. we had a binary node in
mind
> [11/17/2004 10:43 PM] <gdaniels> We've already got the notion that Objects
might be hanging off OmElements
> [11/17/2004 10:43 PM] <alek_s> i think it would be good to get few exampel
of MTOM/XOP messages over HTTP/MIMR and write a simple example hot og
generate them in OM ...
> [11/17/2004 10:43 PM] <Ajith> a new node for the OM that stores a binary
stream
> [11/17/2004 10:43 PM] -->| dims (~dims@h00045ad8e984.ne.client2.attbi.com)
has joined #apache-axis
> [11/17/2004 10:43 PM] <gdaniels> hi dims
> [11/17/2004 10:43 PM] <alek_s> hi dims
> [11/17/2004 10:43 PM] <Srinath> hi dims
> [11/17/2004 10:43 PM] <gdaniels> we're talking OM
> [11/17/2004 10:43 PM] <alek_s> and MTOM
> [11/17/2004 10:44 PM] <gdaniels> and data binding (oh my!)
> [11/17/2004 10:44 PM] <alek_s> i think theremay be different kinds of
binary content
> [11/17/2004 10:44 PM] <Srinath> glen: there is a proposal for handler MTOM
using a binary node in OM?
> [11/17/2004 10:44 PM] <alek_s> streamed form files (backed by fiesystem),
data bases or more (like DataHandler)
> [11/17/2004 10:44 PM] <gdaniels> Srinath: s/handler/handling/ ?
> [11/17/2004 10:44 PM] <Srinath> handle :)
> [11/17/2004 10:45 PM] <alek_s> in ither words there is need for
flexibility and multiple implementations of XmInclude
> [11/17/2004 10:45 PM] <Srinath> Binary node like textnode .. that hold the
Binary data.. and know how to read or write them
> [11/17/2004 10:45 PM] <alek_s> which gets back to the point: how engine
will pass and lifecycle streams in/out XmlInclude
> [11/17/2004 10:46 PM] <alek_s> Srinath: yes
> [11/17/2004 10:46 PM] <gdaniels> alek: Can DataHandlers be used to front
files?
> [11/17/2004 10:46 PM] <alek_s> Srinath: but it may not knwo how to write
until engine/transport is accessed
> [11/17/2004 10:46 PM] <gdaniels> i.e. can I make a DataHandler that will
read a file when its contents are asked for
> [11/17/2004 10:46 PM] <alek_s> glen: i think so (i would need to check it
for 100%)
> [11/17/2004 10:47 PM] <alek_s> still you need to stream incoming message
attachments into files etc. - and this is done by engine right?
> [11/17/2004 10:47 PM] <gdaniels> I think maybe yes also. If that's the
case, why not just use DataHandlers for all binary content?
> [11/17/2004 10:47 PM] <gdaniels> alek: it's done by someone
> [11/17/2004 10:47 PM] <gdaniels> the OM would have the DataHandlers
attached to it
> [11/17/2004 10:47 PM] <alek_s> XmlInclude that knows all XOP seems better
fit to support MTOM
> [11/17/2004 10:48 PM] <alek_s> internally XmlInclude can use DataHandler?
> [11/17/2004 10:48 PM] <Srinath> the binary node can hida a data handler ?
> [11/17/2004 10:48 PM] <gdaniels> I'd like to see what you think the
interface for XmlInclude looks like
> [11/17/2004 10:48 PM] <gdaniels> I'm not seeing it yet, but maybe you
could check in a proposal or send it to the list?
> [11/17/2004 10:49 PM] <alek_s> there is lot of crap in DataHandler that is
not needed in MTOM
> [11/17/2004 10:49 PM] <alek_s>
http://java.sun.com/products/javabeans/glasgow/javadocs/javax/activation/DataHandler.html
> [11/17/2004 10:49 PM] <gdaniels> But DataHandler is the standard way to
deal with MIME stuff and that's what we'll have
> [11/17/2004 10:49 PM] <alek_s> XmlInclude would encapsulate exactly what
is in XOM/MTOM ...
> [11/17/2004 10:49 PM] <Ajith> IMHO xmlinclude seems to be another name for
what we suggest as the OmBinaryNode
> [11/17/2004 10:49 PM] <gdaniels> Ajith: And that's in one of the scratch
areas already
> [11/17/2004 10:49 PM] <gdaniels> ?
> [11/17/2004 10:50 PM] <Chinthaka> ajith : yes
> [11/17/2004 10:50 PM] <alek_s> and sure i think it should be implemented
with DataHandler when needed
> [11/17/2004 10:50 PM] <alek_s> Ajith: yes
> [11/17/2004 10:51 PM] <Ajith> glen ; we dont have a binary node still in
the implementations we have in the scratch. Do we Srinath?
> [11/17/2004 10:51 PM] <alek_s> i think XopInclude should be consistent
with Infoset defiend in XOP
> [11/17/2004 10:51 PM] <alek_s>
http://www.w3.org/TR/2004/NOTE-xopinc-FAQ-20040608/#q5
> [11/17/2004 10:51 PM] <Chinthaka> Since, we *may* not implement MTOM for
the time being, shall we focus a bit on data binding as well ??
> [11/17/2004 10:52 PM] <Chinthaka> :(
> [11/17/2004 10:52 PM] <alek_s> Chinthaka: that is the reason i have put
goals so we can discuss it and make decision
> [11/17/2004 10:52 PM] <alek_s> If we do not implement MTOM we do not need
BinaryNodes
> [11/17/2004 10:52 PM] <gdaniels> Chinthaka: I'd be happy to talk data
binding
> [11/17/2004 10:52 PM] <Chinthaka> glen : :)
> [11/17/2004 10:53 PM] <alek_s> however that means that OM API may need to
have drastical chnages in future
> [11/17/2004 10:53 PM] <alek_s> including how binary data is handled
througout engine ...
> [11/17/2004 10:53 PM] <Srinath> let us add at least the interface Binary
node to OM API
> [11/17/2004 10:53 PM] <Srinath> may be implement ti later
> [11/17/2004 10:53 PM] <gdaniels> As I see it, an OMElement is *either*
going to have XML content (children/attributes) *or* Object content (a Java
Object hanging off it)
> [11/17/2004 10:53 PM] <alek_s> Srinath yes - i think as first step we can
add XopInclude (OmBE) and have it impelment all infoset defined in XOP
> [11/17/2004 10:54 PM] <gdaniels> If it's got Object content, and you write
the element out, it calls out to a SerializationContext to do the work of
pushing the XML events
> [11/17/2004 10:54 PM] <Srinath> glen: Object contenet is set via a build
that works on Object rather than a stream
> [11/17/2004 10:54 PM] <alek_s> and for now have it serialized as BASE64 so
it is "unoptimized" MTOM?!
> [11/17/2004 10:54 PM] <Srinath> build=builder
> [11/17/2004 10:54 PM] <gdaniels> Srinath: Or by just manually creating an
OM hierarchy
> [11/17/2004 10:55 PM] <Srinath> glen: we need differ creating OM As much
as possible
> [11/17/2004 10:55 PM] <alek_s> how such minimum MTOM without optimizations
sound?
> [11/17/2004 10:55 PM] <Srinath> at the reposne side as well ..
> [11/17/2004 10:55 PM] <Chinthaka> I see in most of the data binding tools
today SAX events are taken as inputs for unmarshalling
> [11/17/2004 10:55 PM] <gdaniels> Chinthaka: We can gen SAX from pull
events
> [11/17/2004 10:56 PM] <Chinthaka> yeah
> [11/17/2004 10:56 PM] <Srinath> if body not touched we write the object
directly to out stream
> [11/17/2004 10:56 PM] <gdaniels> Our deserializers will probably operate
directly on pull
> [11/17/2004 10:56 PM] <Chinthaka> so we can use existing OM API to do that
> [11/17/2004 10:56 PM] <alek_s> also there is a related issue in goals:
what is API to access SOAP:Body? see FrontPage/Architecture/OMGoals
> [11/17/2004 10:56 PM] <Srinath> glen +1 for deserializers
> [11/17/2004 10:56 PM] <gdaniels> Srinath: yup
> [11/17/2004 10:56 PM] <Ajith> glen : yes so basically we provide
pullevent (or pull wrapped in sax) to the external data binders
> [11/17/2004 10:56 PM] <Ajith> is it?
> [11/17/2004 10:56 PM] <gdaniels> Ajith: yes
> [11/17/2004 10:57 PM] <Chinthaka> so thats gr8
> [11/17/2004 10:57 PM] <gdaniels> and cache the object they return in the
OMElement
> [11/17/2004 10:57 PM] <alek_s> Ajith: you mean providing sax (push)
wrapping pull stream?
> [11/17/2004 10:57 PM] <Chinthaka> glen : didn't get u
> [11/17/2004 10:57 PM] <Ajith> Alek : yeah
> [11/17/2004 10:57 PM] <Chinthaka> alek : yes
> [11/17/2004 10:57 PM] <gdaniels> Chinthaka: You've got an OMElement e;
> [11/17/2004 10:57 PM] <Ajith> our OM is exposed to Daabinders through the
pull warpper
> [11/17/2004 10:57 PM] <gdaniels> You do "Object foo = e.getObjectValue();"
> [11/17/2004 10:58 PM] <gdaniels> under the covers, the OM code calls out
to a deserializer to translate the XML pull events into an Object
> [11/17/2004 10:58 PM] <Srinath> glen: by keeping object chached inside a
Builder we can avoid OM havig code for object specific code
> [11/17/2004 10:58 PM] <gdaniels> the Object gets returned to you, and also
cached in the OMElement
> [11/17/2004 10:58 PM] <Ajith> the pull wrapper may be wrapped in a sax
wrapper again depending on the need of the data binder
> [11/17/2004 10:58 PM] <gdaniels> so next time you just get it instead of
deserializing
> [11/17/2004 10:58 PM] -->| dominik (~dominik@adsl-64-142-27-168.sonic.net)
has joined #apache-axis
> [11/17/2004 10:58 PM] <Srinath> it is builder that changed not OM element
> [11/17/2004 10:58 PM] <gdaniels> Srinath: didn't get you?
> [11/17/2004 10:58 PM] <Chinthaka> glen : what I thought was
> [11/17/2004 10:59 PM] <Chinthaka> there is a Navigator sort of thing
> [11/17/2004 10:59 PM] <Chinthaka> when you give an OMElement to that
> [11/17/2004 10:59 PM] <gdaniels> Ajith: Yes
> [11/17/2004 10:59 PM] <alek_s> glen: this gets back to issue ow to acccess
SOAP:Body as stream
> [11/17/2004 10:59 PM] <Chinthaka> u can get pull events from that
Navigator
> [11/17/2004 10:59 PM] <Srinath> glen: for each OM node there is a Builder
.. OM node can reguest builder to proceed and build little bit more
> [11/17/2004 10:59 PM] <alek_s> Navigator?
> [11/17/2004 10:59 PM] <Srinath> glen: in the object case builder work on a
object
> [11/17/2004 11:00 PM] <Chinthaka> alek : yes, this will help to get pull
evens
> [11/17/2004 11:00 PM] <Chinthaka> to a given node
> [11/17/2004 11:00 PM] <Srinath> glen: usual cse builder work on a pull
parser
> [11/17/2004 11:00 PM] <Chinthaka> so OM is not polluted with that code
> [11/17/2004 11:01 PM] <gdaniels> Srinath: Right. So walk us through this?
Pull parser pulls in XML and builds OM.
> [11/17/2004 11:01 PM] <gdaniels> Let's say the whole OM got built
> [11/17/2004 11:01 PM] <Ajith> on demand!
> [11/17/2004 11:01 PM] <gdaniels> Let's assume someone asked for the whole
structure, though, for now
> [11/17/2004 11:01 PM] <gdaniels> So we've got the OMElements all the way
down
> [11/17/2004 11:01 PM] <Chinthaka> OMNode, will call the builder to proceed
> [11/17/2004 11:01 PM] <gdaniels> (we'll do the stream case next)
> [11/17/2004 11:02 PM] <Chinthaka> only if that element is not complete !!
> [11/17/2004 11:02 PM] <gdaniels> ok
> [11/17/2004 11:02 PM] <Ajith> then when the databinder needs it the
navigator navigates the structure generating pull events
> [11/17/2004 11:02 PM] <gdaniels> So now someone calls e.getObjectValue()
> [11/17/2004 11:02 PM] <gdaniels> What happens?
> [11/17/2004 11:03 PM] <Chinthaka> glen : can u tell me what do u expect
from getObjectValue ?
> [11/17/2004 11:03 PM] <alek_s> what is getObejctValue???
> [11/17/2004 11:03 PM] <Chinthaka> did I miss something, earlier ? :(
> [11/17/2004 11:03 PM] <gdaniels> The thingy that says "get me the
deserialized value of this node"
> [11/17/2004 11:03 PM] <alek_s> it returns *canonical* representation
"eserialzied" of XML Infoset?
> [11/17/2004 11:03 PM] <alek_s> tha is not possible
> [11/17/2004 11:04 PM] <alek_s> there are many possible data bindinf
representations for any XML infoset
> [11/17/2004 11:04 PM] <gdaniels> Yes
> [11/17/2004 11:04 PM] <alek_s> like xsd:date ...
> [11/17/2004 11:04 PM] <gdaniels> That's why there's a
DeserializationContext which knows how to do the actual work
> [11/17/2004 11:04 PM] <alek_s> you can bind to Long, Date, XmlDate (in
XmlBeans), etc.
> [11/17/2004 11:04 PM] <alek_s> so you put DeserCtx in OM?
> [11/17/2004 11:04 PM] <Ajith> nope
> [11/17/2004 11:04 PM] <alek_s> or you pass it to OM when it needs it?
getOV(ctx)?
> [11/17/2004 11:04 PM] <Chinthaka> alek : I hope not
> [11/17/2004 11:05 PM] <Ajith> here let me make this clear
> [11/17/2004 11:05 PM] <gdaniels> alek: We didn't get that far when
discussing at the F2F
> [11/17/2004 11:05 PM] <Srinath> glen:pull parser pulls little bit more ..
and if om sees it has not build enough he will ask builder to proceed bit
more
> [11/17/2004 11:05 PM] <gdaniels> I could see either
> [11/17/2004 11:05 PM] <alek_s> i would liek OM to support very fexible
data binding
> [11/17/2004 11:05 PM] <alek_s> (hey see one of the goals: AXIOM API is
designed to support data bindings and XML transformations and AXIOM API
should work well with any data binding framework (XPath, XSLT,
JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
> [11/17/2004 11:05 PM] <Ajith> we have a dataBinder class that has bind
method that retruns an array of objects and takes a pullparser wrapper
> [11/17/2004 11:06 PM] <gdaniels> +1 for flexible data binding
> [11/17/2004 11:06 PM] <Srinath> glen: that happens until om parse what
ever requested (e.g. want to get all child elements)
> [11/17/2004 11:06 PM] <Ajith> the engine calls the bind method with the
pull parser
> [11/17/2004 11:06 PM] <alek_s> i think there are many many ways that
people want their XML served :)
> [11/17/2004 11:06 PM] <alek_s> so maybe DeserCtx gets passed to builder?
> [11/17/2004 11:07 PM] <alek_s> OMDocument builderImpl.parse(stream,
deserCtx)?
> [11/17/2004 11:07 PM] <gdaniels> I think we need to start building sample
use cases to get this right
> [11/17/2004 11:07 PM] <gdaniels> alek: That's certainly a good thought
> [11/17/2004 11:07 PM] <alek_s> +1 to use cases !!!!
> [11/17/2004 11:07 PM] <gdaniels> That's along the lines of what I was
thinking back in Sri Lanka
> [11/17/2004 11:08 PM] <gdaniels> but actual deserialization doesn't occur
until something is asked for, just like pull doesn't happen until XML is
asked for
> [11/17/2004 11:09 PM] <alek_s> glen: that is good for efficiency so i am
all for it
> [11/17/2004 11:09 PM] <gdaniels> Ideally, I'd like to see data binding and
MTOM support use the exact same APIs
> [11/17/2004 11:09 PM] <gdaniels> They both represent getting some non-XML
content (binary data or Java objects) from a certain place in the infoset
> [11/17/2004 11:09 PM] <gdaniels> s/getting/getting or putting/
> [11/17/2004 11:10 PM] <gdaniels> So the API lets you get or drop "stuff"
at various places, and then the stuff behind the API (the
Builders/Writers/Serializers/Deserializers) knows how to make that actually
work
> [11/17/2004 11:10 PM] <alek_s> still after all is said and done what we
have is jsut XML Infoset
> [11/17/2004 11:11 PM] <alek_s> just that we "optimize" or create "views"
on XML Infoset
> [11/17/2004 11:11 PM] <gdaniels> alek: Yes, and if you never use the
"objecty" methods, you can treat it as infoset
> [11/17/2004 11:11 PM] <gdaniels> yes yes
> [11/17/2004 11:11 PM] <alek_s> so we can access it with Java Objects (data
binding) or send it efficiently (MTOM that annotates XML Infoset)
> [11/17/2004 11:11 PM] <gdaniels> :)
> [11/17/2004 11:12 PM] <gdaniels> that's how I'm seeing it at the moment
> [11/17/2004 11:12 PM] <alek_s> it seems that finally people see value in
XML and do nto try to use it as RPC transfer ...
> [11/17/2004 11:12 PM] <gdaniels> stop dissing RPC, buddy.
> [11/17/2004 11:12 PM] <gdaniels> :)
> [11/17/2004 11:12 PM] <gdaniels> THERE IS NOTHING WRONG WITH RPCs IN THE
RIGHT CASES! (dammit)
> [11/17/2004 11:13 PM] <alek_s> i like RPC i wrote RMI impl - check SoapRMI
...
> [11/17/2004 11:13 PM] <gdaniels> I know. :) I just figured you'd
converted entirely.
> [11/17/2004 11:13 PM] <alek_s> though still there is impedance mismatch if
you try to do RPC and XML documents messaging ...
> [11/17/2004 11:13 PM] <gdaniels> We're still going to support RPCs, and
that will likely be an early use case...
> [11/17/2004 11:13 PM] <alek_s> i have different angle: now all is XML
Infoset :) new religion :)
> [11/17/2004 11:14 PM] <gdaniels> Well, good luck writing your programming
language that has elements and attributes as native data types...
> [11/17/2004 11:14 PM] <gdaniels> Oh wait that's XQuery... :)
> [11/17/2004 11:14 PM] <alek_s> and i am fine if somebody want to generate
all XML Infoset from RPC - "not that there is anything wrong with that"
> [11/17/2004 11:15 PM] <alek_s> haha
> [11/17/2004 11:15 PM] <gdaniels> So others, any commentary on all that?
> [11/17/2004 11:15 PM] <Ajith> on RPC ? :)
> [11/17/2004 11:16 PM] <gdaniels> no, the infoset/MTOM/data binding
stuff... :)
> [11/17/2004 11:16 PM] <alek_s> anybody: any thoughts about
FrontPage/Architecture/OMGoals
> [11/17/2004 11:16 PM] <alek_s> something is not clear? missing? should be
added?
> [11/17/2004 11:16 PM] <Chinthaka> alek : a suggestion !!
> [11/17/2004 11:16 PM] <alek_s> re-prioritized?
> [11/17/2004 11:16 PM] <Srinath> :) om seem to be tricker tha I thought ;)
> [11/17/2004 11:16 PM] <alek_s> go ahead
> [11/17/2004 11:17 PM] <Chinthaka> shall we put all the wiki pages in one
place
> [11/17/2004 11:17 PM] <Ajith> seems quite complete but I might make some
changes later
> [11/17/2004 11:17 PM] <alek_s> Srinath: if we get it right OM becomes
strong backbone of AXIS2, if not ...
> [11/17/2004 11:17 PM] <Chinthaka> and extract all the need information and
re-create the pages
> [11/17/2004 11:17 PM] <alek_s> Ajith: please do - it is great if OMGoals
is live document
> [11/17/2004 11:17 PM] <gdaniels> alek: If we get it right OM becomes an
API that a lot of other projects want to steal from Axis2...
> [11/17/2004 11:18 PM] <Chinthaka> glen : wow, boosting moral !!!
> [11/17/2004 11:18 PM] <Chinthaka> ;)
> [11/17/2004 11:18 PM] <gdaniels> Well, it's a big "if" :)
> [11/17/2004 11:18 PM] <alek_s> we are like cooking - we got ingredients
(goals, reqs, prototypes) and we put them in OM - hopefully we get soemthing
worth stealing :-)
> [11/17/2004 11:18 PM] <Srinath> :)
> [11/17/2004 11:18 PM] <Chinthaka> :D
> [11/17/2004 11:19 PM] <alek_s> stealing is sure notion that project is
succesulf ;->
> [11/17/2004 11:19 PM] <gdaniels> Anybody know how big/fast JDOM is these
days, by the way?
> [11/17/2004 11:19 PM] <alek_s> JDOM is very big - it is unvbelivable how
many methods are there ...
> [11/17/2004 11:19 PM] <Srinath> unfurtunatly they can not steel it since
everything is open ;)
> [11/17/2004 11:19 PM] <Srinath> unfourtunatly
> [11/17/2004 11:19 PM] <alek_s> steal in good sense, "extended" sharing and
reuse
> [11/17/2004 11:19 PM] <gdaniels> Srinath: Picky, picky. :) "use" then...
> [11/17/2004 11:19 PM] <Chinthaka> I did a OM comparison with JDOM
> [11/17/2004 11:20 PM] <Srinath> :D
> [11/17/2004 11:20 PM] <Chinthaka> seems like OM Linked List impl is faster
than JDOM !!
> [11/17/2004 11:20 PM] <Chinthaka> seems like cooking seems fine ;)
> [11/17/2004 11:21 PM] <gdaniels> ok, I think I'm going to head to bed now,
folks.
> [11/17/2004 11:21 PM] <alek_s> i think we got more ro less covered from
ChatAgenda? http://wiki.apache.org/ws/ChatAgenda_2f20041117#preview
> [11/17/2004 11:21 PM] <gdaniels> I'll try to write up some of the
databinding/mtom stuff around the current OM proposals
> [11/17/2004 11:22 PM] <Srinath> bye glen .. will try to get that Binary
node up ..
> [11/17/2004 11:22 PM] <alek_s> i think we gettign close to actually maybe
understand what it takes in APU to do MTOM and data-binding ...
> [11/17/2004 11:22 PM] <gdaniels> alek: I think so too, now we just need to
see it in code.
> [11/17/2004 11:23 PM] <gdaniels> alek: You going to send the log?
> [11/17/2004 11:25 PM] <Srinath> are we done :)
> [11/17/2004 11:25 PM] <gdaniels> think so... :) Alek, if you don't send
the log tonight I'll do it tomorrow.
> [11/17/2004 11:25 PM] <gdaniels> Good night folks!
> [11/17/2004 11:25 PM] <Chinthaka> good night, sweet OM Dreams !!
> [11/17/2004 11:25 PM] <alek_s> i will send logs
> [11/17/2004 11:26 PM] |<-- gdaniels has left irc.freenode.net ()
> [11/17/2004 11:26 PM] <alek_s> good night/morning everybody!
> [11/17/2004 11:26 PM] <Srinath> bye all
> [11/17/2004 11:26 PM] <alek_s> bye
> [11/17/2004 11:26 PM] <--| farhaan has left #apache-axis
> [11/17/2004 11:26 PM] |<-- Srinath has left irc.freenode.net ("Client
Exiting")
> [11/17/2004 11:26 PM] <--| Deepal has left #apache-axis
> [11/17/2004 11:26 PM] |<-- chathura has left irc.freenode.net ()
> [11/17/2004 11:26 PM] |<-- Chinthaka has left irc.freenode.net ("Leaving")
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>