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/09/22 16:40:44 UTC
[Axis2] IRC chat log 2004-09-22
summary: we have discussed OM prorotype implementation that uses table model
(it is not classical Xalan DTM or DBXML DTSM as it isuses objects intead of ints?)
http://wiki.apache.org/ws/FrontPage/Architecture/OMTableModel
and few concerns were raised about its flexibility, API (JDOM like?)
and MTOM support, then talked about how to deal with deployment
descriptors (use OM, XStream, JDOM, ?) and what exactly OM streaming
means and what are use cases - Wiki page was created to record them:
http://wiki.apache.org/ws/FrontPage/Architecture/OMUseCases
thanks,
alek
[9/22/2004 8:05 AM] <gdaniels> So what's on our agenda for today?
[9/22/2004 8:05 AM] =-= YOU are now known as alek_s
[9/22/2004 8:05 AM] <Srinath> hi all
[9/22/2004 8:06 AM] <gdaniels> Hi Alek
[9/22/2004 8:06 AM] <alek_s> hi geln
[9/22/2004 8:06 AM] <alek_s> hi all
[9/22/2004 8:06 AM] <Srinath> hi glen
[9/22/2004 8:06 AM] <alek_s> hi Glen
[9/22/2004 8:06 AM] <gdaniels> hey Srinath
[9/22/2004 8:06 AM] <chathura> think we need to get the new OM thingy cleared out today
[9/22/2004 8:07 AM] <Chinthaka> yeah, thats good
[9/22/2004 8:07 AM] <gdaniels> (excuse me if I type with my mouth full - I'm eating breakfast :))
[9/22/2004 8:07 AM] <alek_s> cleared?
[9/22/2004 8:08 AM] -->| Ajith (~Miranda@220.247.229.84) has joined #apache-axis
[9/22/2004 8:08 AM] <Ajith> Finally
[9/22/2004 8:08 AM] <chathura> i mean about the new table model that has been proposed
[9/22/2004 8:08 AM] <gdaniels> So have people been implementing OM prototypes? I'm sorry I haven't
really been tuned in lately due to crazy standards stuff which has been going on....
[9/22/2004 8:08 AM] <Chinthaka> hope u all take a look at the OM table model
[9/22/2004 8:09 AM] <Chinthaka> in Wiki
[9/22/2004 8:09 AM] <gdaniels> URL?
[9/22/2004 8:09 AM] -->| dasarathw (~dasarath@220.247.229.84) has joined #apache-axis
[9/22/2004 8:09 AM] <dasarathw> Hi everyone!
[9/22/2004 8:09 AM] <Ajith> http://wiki.apache.org/ws/FrontPage/Architecture/OMTableModel
[9/22/2004 8:09 AM] -->| Farhaan (~farhaan@203.143.53.73) has joined #apache-axis
[9/22/2004 8:09 AM] <Srinath> tble model we get idea from xalan :)
[9/22/2004 8:10 AM] <Srinath> DTM
[9/22/2004 8:10 AM] <Farhaan> Hi guys
[9/22/2004 8:10 AM] <Ajith> well all of us have been working on ONE protoype
[9/22/2004 8:10 AM] <Srinath> hi furhaan
[9/22/2004 8:10 AM] <Ajith> Hi farhaan
[9/22/2004 8:10 AM] <alek_s> hi Farhaan
[9/22/2004 8:10 AM] <chathura> hi Farhaan
[9/22/2004 8:10 AM] <Farhaan> got a little bit late...hope i didn't miss to much
[9/22/2004 8:10 AM] <dasarathw> hi Farhaan
[9/22/2004 8:10 AM] <Chinthaka> one more hi farhaan :)
[9/22/2004 8:10 AM] <Ajith> :)
[9/22/2004 8:11 AM] <Farhaan> :)
[9/22/2004 8:11 AM] <Srinath> back to OM
[9/22/2004 8:11 AM] <Srinath> :)
[9/22/2004 8:11 AM] <Ajith> yep
[9/22/2004 8:11 AM] <gdaniels> So this table model is pretty similar in design to the SAX recorder, no?
[9/22/2004 8:11 AM] <Srinath> is it?
[9/22/2004 8:11 AM] <Srinath> :)
[9/22/2004 8:11 AM] <Ajith> well I am not sure
[9/22/2004 8:11 AM] <gdaniels> well, not quite.
[9/22/2004 8:12 AM] <gdaniels> Doesn't have the end events and such, just captures the data for the nodes
[9/22/2004 8:12 AM] <dasarathw> we don't record events
[9/22/2004 8:12 AM] <Srinath> plus it is streaming
[9/22/2004 8:12 AM] <dasarathw> AXTM is a more
[9/22/2004 8:12 AM] <dasarathw> cooked form of
[9/22/2004 8:12 AM] <dasarathw> recording than
[9/22/2004 8:12 AM] <chathura> well it might be seen as a pull recording
[9/22/2004 8:12 AM] <dasarathw> just recording events
[9/22/2004 8:12 AM] <dasarathw> anyway
[9/22/2004 8:13 AM] <dasarathw> I think we shouldn't call it a recorder at all
[9/22/2004 8:13 AM] <Ajith> Dasarath : yeah we shouldn't
[9/22/2004 8:13 AM] <Srinath> dasarathw: we can call it ayhting:)
[9/22/2004 8:13 AM] <Ajith> it is more of a MODEL
[9/22/2004 8:13 AM] <chathura> :-D
[9/22/2004 8:13 AM] <dasarathw> no anything hay
[9/22/2004 8:13 AM] <Ajith> of the XML doc
[9/22/2004 8:13 AM] <dasarathw> +1 for MODEL
[9/22/2004 8:13 AM] <gdaniels> +1 model
[9/22/2004 8:14 AM] <Srinath> +1 :) dasrath need exact words
[9/22/2004 8:14 AM] <dasarathw> ;)
[9/22/2004 8:14 AM] <Ajith> BTW deepal is with me
[9/22/2004 8:15 AM] <chathura> hi deepal
[9/22/2004 8:15 AM] <Ajith> alek, have you looked into this table thing?
[9/22/2004 8:15 AM] <gdaniels> q: why not have comments/CDATA be separate kinds of rows?
[9/22/2004 8:15 AM] <Srinath> it recored reduced nuber of pull events ... the pull stream can be
regenerated from the model easily
[9/22/2004 8:15 AM] <Ajith> deepal says Hi
[9/22/2004 8:15 AM] <Chinthaka> glen : we looked at DOM API
[9/22/2004 8:15 AM] <Srinath> glen:misc rows stored with row type
[9/22/2004 8:15 AM] <Chinthaka> and in that it seems that the information we have in those are almost
the same
[9/22/2004 8:16 AM] <Chinthaka> so we decided to have one table to store texts, comments, CDATA
[9/22/2004 8:16 AM] -->| Deeapl2 (~deepal@220.247.229.84) has joined #apache-axis
[9/22/2004 8:16 AM] |<-- Ajith has left irc.freenode.net (Read error: 104 (Connection reset by peer))
[9/22/2004 8:16 AM] <Chinthaka> and to have a column to say, the type of the information item
[9/22/2004 8:16 AM] <gdaniels> So the diagram of the Text Table should get fixed to add a "type"
column, then?
[9/22/2004 8:16 AM] <dasarathw> yes
[9/22/2004 8:16 AM] <Srinath> misc row = less common rows e.g. CDDATA commnet
[9/22/2004 8:17 AM] <Deeapl2> Deeapl2 is Deepal
[9/22/2004 8:17 AM] <Chinthaka> I think that has been stated in the sentence
[9/22/2004 8:17 AM] <gdaniels> ok
[9/22/2004 8:17 AM] <dasarathw> there are couple of issues
[9/22/2004 8:17 AM] <gdaniels> So where do we record children?
[9/22/2004 8:17 AM] <dasarathw> like ppl cannot use instanceof with our object model
[9/22/2004 8:17 AM] <gdaniels> Or do you have to walk the table backwards to find them?
[9/22/2004 8:17 AM] <dasarathw> certainly not
[9/22/2004 8:17 AM] <Farhaan> no that is not necessary
[9/22/2004 8:18 AM] <dasarathw> parent knows the first child
[9/22/2004 8:18 AM] <Chinthaka> each children has a reference to parent
[9/22/2004 8:18 AM] <dasarathw> and every child knows his parent and the next sibling
[9/22/2004 8:18 AM] |<-- Deepal has left irc.freenode.net (Read error: 110 (Connection timed out))
[9/22/2004 8:18 AM] <dasarathw> so searching is not a problem
[9/22/2004 8:18 AM] <gdaniels> I don't see the "first child" and "sibling" parts in the tables
[9/22/2004 8:18 AM] -->| Ajith (~Miranda@220.247.229.84) has joined #apache-axis
[9/22/2004 8:18 AM] <dasarathw> Oops!
[9/22/2004 8:19 AM] <dasarathw> sorry about that glen
[9/22/2004 8:19 AM] <Ajith> Damn this Miranda
[9/22/2004 8:19 AM] <gdaniels> ah, I see it in the diagram below though!
[9/22/2004 8:19 AM] <dasarathw> it should be there
[9/22/2004 8:19 AM] <gdaniels> ok
[9/22/2004 8:19 AM] <dasarathw> hope u got what I was trying to say
[9/22/2004 8:19 AM] <dasarathw> I will add it pronto
[9/22/2004 8:19 AM] <Ajith> I got disconnected and lost a lot of facts :(
[9/22/2004 8:19 AM] <gdaniels> So there seem to be some tradeoffs here.
[9/22/2004 8:19 AM] <Deeapl2> what ?
[9/22/2004 8:19 AM] <gdaniels> In particular, we lose a little cleanliness with APIs/objects by doing
it this way
[9/22/2004 8:19 AM] <gdaniels> hopefully in exchange for speed and memory benefits
[9/22/2004 8:20 AM] <Chinthaka> yes
[9/22/2004 8:20 AM] <Chinthaka> we wanted to have less memory footprint
[9/22/2004 8:20 AM] <gdaniels> I'm just wondering if we're sure it's worth it
[9/22/2004 8:20 AM] <Ajith> well kind of yes
[9/22/2004 8:20 AM] <alek_s> aboout speed an memory benefits: they should nto be assumed but verified
by tests ...
[9/22/2004 8:20 AM] <Deeapl2> yep
[9/22/2004 8:20 AM] <gdaniels> Alek: that's what I was getting to. :)
[9/22/2004 8:20 AM] <dasarathw> true
[9/22/2004 8:21 AM] <alek_s> especially that new JVMs are optimzied for fast Objects and no longer it
is so fast to use ints and other C tricks ...
[9/22/2004 8:21 AM] <gdaniels> My instinct would be to build the model with objects/references first,
see how that does, and then see if we feel the need to further optimize
[9/22/2004 8:21 AM] <Srinath> let us run the tests and see it is at least equal ..:)
[9/22/2004 8:21 AM] <dasarathw> How about pooling against using new to create objects
[9/22/2004 8:21 AM] <dasarathw> Do u chaps think we can gain speed by that?
[9/22/2004 8:22 AM] <Ajith> we have looked into commons pooling also
[9/22/2004 8:22 AM] <Srinath> glen:it is build with object referances now
[9/22/2004 8:22 AM] <Ajith> I think we explained that in the wiki too
[9/22/2004 8:22 AM] <dasarathw> for the memory footprint
[9/22/2004 8:22 AM] <Ajith> Srinath : yeah. instead of integer keys we have object references now
[9/22/2004 8:23 AM] <Srinath> we talk about using int .. but thought serching will take the advantage away
[9/22/2004 8:23 AM] <dasarathw> do we have any test cases?
[9/22/2004 8:23 AM] <alek_s> did you look on sosnoski.com reference i sent?
[9/22/2004 8:24 AM] <Ajith> Alek : mmm yes. Bur our impl is not in a state to be tested
[9/22/2004 8:24 AM] <Chinthaka> I think we will be running those tests against the prototype we are
writing these days
[9/22/2004 8:24 AM] <dasarathw> nope sorry alek
[9/22/2004 8:24 AM] <Ajith> i mean it is not complete yet
[9/22/2004 8:25 AM] <alek_s> this tests is good that it tests both performance (including load and save
time that are critical for SOAP OM) *and* tries to estimate memory usage
[9/22/2004 8:25 AM] <Deeapl2> sure , we will do it
[9/22/2004 8:25 AM] <Srinath> we plan for do bit of pooling that would add up to our advantage
[9/22/2004 8:26 AM] <chathura> in terms of memory footprint i might add
[9/22/2004 8:26 AM] <Chinthaka> we thought of pooling rows of the tables, etc.,
[9/22/2004 8:27 AM] <Ajith> yeah That should improve our performance
[9/22/2004 8:27 AM] <Deeapl2> regarding memory footprint dbXML has good exampl
[9/22/2004 8:27 AM] <Deeapl2> http://www.dbxml.com/docs/dtsm.html
[9/22/2004 8:27 AM] <gdaniels> So when you say "rows of the table", what differentiates those from
"objects"?
[9/22/2004 8:27 AM] <Deeapl2> bcoz they have somwaht similar model to us
[9/22/2004 8:28 AM] <Srinath> glen:actually they implements Node/Elemnt interfaces
[9/22/2004 8:28 AM] <Ajith> rows are object :)
[9/22/2004 8:28 AM] <Chinthaka> I meant objects of rows of tables
[9/22/2004 8:28 AM] <Chinthaka> :)
[9/22/2004 8:28 AM] -->| Ias (~chatzilla@bucket4.ncl.ac.uk) has joined #apache-axis
[9/22/2004 8:28 AM] <gdaniels> I guess what I'm asking here is what's the difference between a "table"
in your minds and an object graph?
[9/22/2004 8:28 AM] <Deeapl2> hi ias
[9/22/2004 8:29 AM] <Ajith> Hi Ias
[9/22/2004 8:29 AM] <Ias> hi all,
[9/22/2004 8:29 AM] <Ias> sorry to be late.
[9/22/2004 8:29 AM] <gdaniels> If you were using arrays for storage and integer indexes, I could see
that... but I'm not sure I get why this is a "table" model
[9/22/2004 8:29 AM] <gdaniels> hi Ias
[9/22/2004 8:29 AM] <Ajith> mmm
[9/22/2004 8:29 AM] <Ajith> A table is a collection of rows in our model
[9/22/2004 8:29 AM] <Deeapl2> glen somthing similar to that
[9/22/2004 8:29 AM] <gdaniels> but you said you replaced the integer references with object references,
right?
[9/22/2004 8:30 AM] <Srinath> glen:no list of childs .. remove the collection classes that usauuly use
to store them
[9/22/2004 8:30 AM] <gdaniels> So there's no "lookup" that happens
[9/22/2004 8:30 AM] <Ias> I have classes Wednesdays, so please forgive me if I can't attend this weekly
meeting :-)
[9/22/2004 8:30 AM] <Ajith> yes but inside the row
[9/22/2004 8:30 AM] <Ajith> I mean the object reference is inside the row object
[9/22/2004 8:30 AM] <gdaniels> So the children are maintained as linked lists instead of arrays.
[9/22/2004 8:30 AM] <Srinath> glen:exactly :)
[9/22/2004 8:31 AM] <dasarathw> rows u mean
[9/22/2004 8:31 AM] <gdaniels> that doesn't seem a big difference
[9/22/2004 8:31 AM] <Ajith> well I would not say linked list
[9/22/2004 8:31 AM] <dasarathw> difference compared to what?
[9/22/2004 8:31 AM] <Srinath> well this support streming well
[9/22/2004 8:31 AM] <gdaniels> linked list vs. array for children
[9/22/2004 8:31 AM] <dasarathw> we can have a hybrid
[9/22/2004 8:31 AM] <dasarathw> if that serves better
[9/22/2004 8:32 AM] <gdaniels> i.e. instead of getChildren() returning an array, you have
getFirstChild() returning a node with a getNextSibling()
[9/22/2004 8:32 AM] <dasarathw> no no
[9/22/2004 8:32 AM] <dasarathw> glen
[9/22/2004 8:32 AM] <dasarathw> are u asking about the API
[9/22/2004 8:32 AM] <Ajith> glen : well not really
[9/22/2004 8:32 AM] <gdaniels> (I'm not suggesting anything here, just trying to understand)
[9/22/2004 8:32 AM] <Deeapl2> ok :)
[9/22/2004 8:32 AM] <dasarathw> and we are helping u do just that:)
[9/22/2004 8:32 AM] <Srinath> yap glen: u r right ..
[9/22/2004 8:32 AM] <Chinthaka> glen , its like this
[9/22/2004 8:32 AM] <gdaniels> yes, I'm asking about the API
[9/22/2004 8:32 AM] <dasarathw> API is DOM
[9/22/2004 8:33 AM] <dasarathw> and nothing else
[9/22/2004 8:33 AM] <dasarathw> but there are couple of best practices
[9/22/2004 8:33 AM] <dasarathw> like
[9/22/2004 8:33 AM] <dasarathw> don't call getSize if possible
[9/22/2004 8:33 AM] <Chinthaka> when one asks for getChildren
[9/22/2004 8:33 AM] <dasarathw> because that would cause the parser to
[9/22/2004 8:33 AM] <dasarathw> advance a lot
[9/22/2004 8:33 AM] <Chinthaka> we return our own implementation of NodeList
[9/22/2004 8:33 AM] <gdaniels> So we've gotten away from the idea of a "lighter" API and are jsut going
to provide a full DOM?
[9/22/2004 8:34 AM] <chathura> think those rows are objects keeping minimal++ set of info needed to
traverse and support the APIs(DOM and pull)
[9/22/2004 8:34 AM] <dasarathw> if people want it yes
[9/22/2004 8:34 AM] <Srinath> glen:we try to implement DOM .. we are doing getNextSibling() actually :)
behind the curtain
[9/22/2004 8:34 AM] <gdaniels> Srinath : ok, got it now.
[9/22/2004 8:34 AM] <Farhaan> yes Glen, that was what was discussed last wednesday
[9/22/2004 8:34 AM] <Ajith> Srinath : exactly
[9/22/2004 8:34 AM] <dasarathw> glen with our impl
[9/22/2004 8:34 AM] <dasarathw> ppl will not be able to use instanceof
[9/22/2004 8:35 AM] <dasarathw> anymore
[9/22/2004 8:35 AM] <dasarathw> because we are using the same class to implement
[9/22/2004 8:35 AM] <dasarathw> several DOM interfaces
[9/22/2004 8:35 AM] <dasarathw> do u think that will be a problem?
[9/22/2004 8:35 AM] <Ajith> Gle : in wiki there is an example which helps to understand this better
[9/22/2004 8:35 AM] <gdaniels> well that seems bad
[9/22/2004 8:35 AM] <Ajith> what?
[9/22/2004 8:35 AM] <dasarathw> come on
[9/22/2004 8:35 AM] <dasarathw> hay
[9/22/2004 8:35 AM] <gdaniels> that means people won't be able to use standard DOM code with our stuff,
right?
[9/22/2004 8:35 AM] <dasarathw> no
[9/22/2004 8:35 AM] <Deeapl2> no
[9/22/2004 8:35 AM] <Chinthaka> but ppl can get the type of the node
[9/22/2004 8:35 AM] <dasarathw> DOM provides another way of doing it
[9/22/2004 8:36 AM] <Deeapl2> they can use it , and we wil provide some api
[9/22/2004 8:36 AM] <Ajith> there can be limitations
[9/22/2004 8:36 AM] <dasarathw> all this time ppl have been using this bad practice
[9/22/2004 8:36 AM] <Chinthaka> using getType method
[9/22/2004 8:36 AM] <dasarathw> and now they are forced to leave it behind
[9/22/2004 8:36 AM] <dasarathw> that
[9/22/2004 8:36 AM] <dasarathw> 's
[9/22/2004 8:36 AM] <dasarathw> all
[9/22/2004 8:36 AM] <dasarathw> and of course if they use C/C++
[9/22/2004 8:36 AM] <dasarathw> they don't get instanceof
[9/22/2004 8:36 AM] <dasarathw> anyway
[9/22/2004 8:36 AM] <Srinath> everybody I got few other issues to raised .. as well , shall I rasided
them as well (Deployment ect ...)
[9/22/2004 8:36 AM] <gdaniels> That's fine then. I just don't want us to do anything which is against
what DOM says, or what people are commonly doing.
[9/22/2004 8:37 AM] <Ajith> yep
[9/22/2004 8:37 AM] <chathura> i think we do support something like getType() for these are we??
[9/22/2004 8:37 AM] <Chinthaka> yes we do
[9/22/2004 8:37 AM] <dasarathw> that's in DOM guys!
[9/22/2004 8:37 AM] <Srinath> (i herd dasarath typed 500wd/min :) to left )
[9/22/2004 8:37 AM] <dasarathw> :)
[9/22/2004 8:37 AM] <gdaniels> keep in mind we need to really be supplying DOM+
[9/22/2004 8:37 AM] <dasarathw> why DOM+
[9/22/2004 8:37 AM] <gdaniels> i.e. we need to deal with MTOM/objects too...
[9/22/2004 8:38 AM] <dasarathw> Oops!
[9/22/2004 8:38 AM] <Srinath> yes glen
[9/22/2004 8:38 AM] <Ajith> ooops !!!!!
[9/22/2004 8:38 AM] <Chinthaka> glen : what do u mean by DOM+
[9/22/2004 8:38 AM] <Ajith> we can t do it with dom alone???
[9/22/2004 8:38 AM] <gdaniels> Chinthaka: We need the ability to get at object representations of
MTOM-optimized elements.
[9/22/2004 8:39 AM] <gdaniels> (and maybe deserialized complexTypes too)
[9/22/2004 8:39 AM] <dasarathw> glen
[9/22/2004 8:39 AM] <gdaniels> Clearly DOM alone doesn't give us that
[9/22/2004 8:39 AM] <dasarathw> do u know of any tutorials for MTOM?
[9/22/2004 8:39 AM] <chathura> well only thing that prevents us from introducing new class is pooling
right?
[9/22/2004 8:39 AM] <Ias> I agree on MTOM.
[9/22/2004 8:39 AM] <Srinath> we got to support MTOM
[9/22/2004 8:40 AM] <Ajith> hmmm... I guess we can extend this table model to support that
[9/22/2004 8:40 AM] <Deeapl2> sure
[9/22/2004 8:40 AM] <dasarathw> no argument on MTOM support
[9/22/2004 8:40 AM] <gdaniels> chathura : why would pooling be a problem?
[9/22/2004 8:40 AM] <alek_s> what will be required for good MTOM implementation ?
[9/22/2004 8:40 AM] <dasarathw> Chathura: what is the problem with pooling?
[9/22/2004 8:40 AM] <chathura> the reason we dont have instance of is
[9/22/2004 8:40 AM] <Ajith> since MTOM will be again a dase64 binary thing
[9/22/2004 8:40 AM] <gdaniels> dasarath : not offhand - the specs and a few web articles... google it
and see what you get. :)
[9/22/2004 8:41 AM] <chathura> because we dont want to create a new class
[9/22/2004 8:41 AM] <dasarathw> :(
[9/22/2004 8:41 AM] <alek_s> i think MTOM should store actual binary content (received from
attachments) and not base64 (unless there is no other choice)
[9/22/2004 8:41 AM] <chathura> cause thts gonna effect the pooling throughput
[9/22/2004 8:41 AM] <gdaniels> Alek : yes
[9/22/2004 8:42 AM] <gdaniels> If you ask for base64, we have to give it to you, but we should avoid
extra encoding/decoding and copying whenever possible.
[9/22/2004 8:42 AM] <Ajith> chathura : do we have a prob with pooling????
[9/22/2004 8:42 AM] <gdaniels> chathura : what do you mean "don't want to create a new class"?
[9/22/2004 8:42 AM] <dasarathw> glen
[9/22/2004 8:42 AM] <chathura> think the problem is in
[9/22/2004 8:42 AM] <dasarathw> if we have less types of objects
[9/22/2004 8:42 AM] <dasarathw> we can do reuse more efficiently
[9/22/2004 8:42 AM] <chathura> text cdata and characterdata interface in dom
[9/22/2004 8:43 AM] <alek_s> i think this is connected to concern about memory - we should be able to
replace parts of Infoset (OM) with specialized classes that provide specialzied storage (like OM)
[9/22/2004 8:43 AM] <alek_s> so that means we may have many types of classes stored in OM ...
[9/22/2004 8:43 AM] <chathura> we have on interface for those three i guess
[9/22/2004 8:43 AM] <chathura> alek i didnt get you!
[9/22/2004 8:44 AM] <chathura> we have reused some classes where dom consider them to be seperate
[9/22/2004 8:44 AM] <Ajith> Alek : We try to minimize the types of objects to make pooling possible
[9/22/2004 8:44 AM] <Srinath> BTW what is the best way to parse the Deployment discrypters in the
deployment , DOM/JAXB/XMLbeans
[9/22/2004 8:45 AM] <chathura> so we can impove pooling
[9/22/2004 8:45 AM] <gdaniels> chathura : we have to make sure that nothing in DOM *actually* considers
them to be separate.
[9/22/2004 8:45 AM] <chathura> ajith:yes
[9/22/2004 8:45 AM] <Srinath> everybody seem to obessed with OM :(
[9/22/2004 8:45 AM] <gdaniels> If we do that, no problem (we're not breaking rules).
[9/22/2004 8:45 AM] <gdaniels> Srinath wants to talk deployment. :)
[9/22/2004 8:45 AM] <dasarathw> no engine
[9/22/2004 8:45 AM] <Deeapl2> no
[9/22/2004 8:45 AM] <Srinath> bit
[9/22/2004 8:45 AM] <Srinath> what is the best way to parse the Deployment discrypters in the
deployment , DOM/JAXB/XMLbeans
[9/22/2004 8:46 AM] <Deeapl2> yes we want to talk abt delployment
[9/22/2004 8:46 AM] <Ajith> yeah I also think we have to address issues other than OM
[9/22/2004 8:46 AM] <dasarathw> +1
[9/22/2004 8:46 AM] <gdaniels> I don't think we should do XMLBeans/JAXB, honestly.
[9/22/2004 8:46 AM] <alek_s> Ajith: this looks to me like a cae of early optimization?
[9/22/2004 8:46 AM] <gdaniels> We should just parse them ourselves
[9/22/2004 8:46 AM] <Deeapl2> I think we have finalize the OM model :)
[9/22/2004 8:46 AM] <dasarathw> alek_s
[9/22/2004 8:46 AM] <alek_s> i tried to avoid it by discussion of requirements and how much they matter ...
[9/22/2004 8:46 AM] <Srinath> am 0+ for auto generation .. not much sure
[9/22/2004 8:46 AM] <dasarathw> what do u mean?
[9/22/2004 8:46 AM] <Ajith> We can talk about OM when the prototype finishes and we do a test of perf
[9/22/2004 8:47 AM] <Ajith> Alek : i did not get you
[9/22/2004 8:47 AM] <gdaniels> I think WRT OM the thing we need first of all is some sample documents
and desired results (i.e. test cases)
[9/22/2004 8:47 AM] <Deeapl2> we will do it ASAP
[9/22/2004 8:47 AM] <alek_s> Ajith: it is not clear to me that pooling is a requirement ...
[9/22/2004 8:47 AM] <gdaniels> including XOP-optimized data...
[9/22/2004 8:47 AM] <chathura> glen: your earlier statement about confused me a bit
[9/22/2004 8:48 AM] <Srinath> glen should we go 4 DOM based manual parsing
[9/22/2004 8:48 AM] <chathura> i mabout dom i mean
[9/22/2004 8:48 AM] <Ajith> Alek : pooling is not actually a part of OM
[9/22/2004 8:48 AM] <dasarathw> yep
[9/22/2004 8:48 AM] <dasarathw> that troubles me too
[9/22/2004 8:48 AM] <Chinthaka> alek : what u say is that we don't need to think abt pooling at this
stage ?
[9/22/2004 8:48 AM] <Ajith> but part of AXIS
[9/22/2004 8:48 AM] <alek_s> Glen: i agree and i would add some tests ...
[9/22/2004 8:48 AM] <Srinath> hwo about use JAXB/XML beans and warp them behind our interfaces
[9/22/2004 8:49 AM] <dasarathw> Srinath is not happy with OM talk!
[9/22/2004 8:49 AM] <gdaniels> chathura : which statement confused you?
[9/22/2004 8:49 AM] <alek_s> Chinthaka: i mean that functionality is more important than implementation
details
[9/22/2004 8:49 AM] <chathura> chathura : we have to make sure that nothing in DOM *actually*
considers them to be separate.
[9/22/2004 8:49 AM] <gdaniels> Srinath : yes, I'd say DOM (or JDOM) manual parsing
[9/22/2004 8:49 AM] <gdaniels> That's the thing about OM - I was hoping we could get some of the
pleasant API of JDOM in there....
[9/22/2004 8:50 AM] <Chinthaka> alek : agreed
[9/22/2004 8:50 AM] <gdaniels> it's much nicer for a Java programmer, less walking nasty NodeLists and
stuff...
[9/22/2004 8:50 AM] <alek_s> Glen: why dont you add JDOM pelasanties to list of desirable properties of
OM in OM requirements Wiki page :)
[9/22/2004 8:50 AM] <gdaniels> chathura : I meant that we should make sure that DOM doesn't actually
claim anywhere that instanceof should be able to differentiate CDATAs and comments, etc.
[9/22/2004 8:50 AM] <Ajith> Glen : we were hoping too. But this XML sec thing needs DOM so we cant help it
[9/22/2004 8:51 AM] <Chinthaka> I agree with glen about the jdom api
[9/22/2004 8:51 AM] <gdaniels> Ajith : I know we NEED to supply DOM - but I thought we'd been
discussing providing a simple Java-friendly API with a DOM shim on top....
[9/22/2004 8:51 AM] <dasarathw> how about searching in OM
[9/22/2004 8:51 AM] <dasarathw> ?
[9/22/2004 8:51 AM] <Srinath> glen .. Chinthaka must be enjoying lot .. he is great supporter of JDOM
[9/22/2004 8:51 AM] <gdaniels> :)
[9/22/2004 8:51 AM] <Chinthaka> :)
[9/22/2004 8:52 AM] <gdaniels> The first version of Axis used JDOM
[9/22/2004 8:52 AM] <Ajith> Glen : now we put the shim of DOM on top a table model
[9/22/2004 8:52 AM] <Ajith> WOW
[9/22/2004 8:52 AM] <dasarathw> at the moment we are thinking of BTrees
[9/22/2004 8:52 AM] <Ajith> glen : really?
[9/22/2004 8:52 AM] <Chinthaka> see ppl knows the advantage of jdom :)
[9/22/2004 8:52 AM] <gdaniels> so maybe we can put a few "pleasant" APIs in our classes too, since
we're extending to allow for MTOM
[9/22/2004 8:53 AM] <Srinath> +1 yes
[9/22/2004 8:53 AM] <alek_s> i think we need some chnages to wiki page to keep it up-to-date with
discussions: http://wiki.apache.org/ws/FrontPage/Architecture/OMRequirements
[9/22/2004 8:53 AM] <gdaniels> Ajith : yep. Was really easy to code. Then it wasn't fast enough. :)
[9/22/2004 8:53 AM] <chathura> glen: tht we discussed to(infact too bad instance of was a operator
otherwise we could have overridden it and thrown an UnsupportedException;)
[9/22/2004 8:53 AM] <chathura> :-D
[9/22/2004 8:54 AM] <gdaniels> chathura : if people are relying on it incorrectly, we should have no
problems.
[9/22/2004 8:54 AM] <gdaniels> They'll just fix their broken code. :)
[9/22/2004 8:54 AM] <chathura> yes yes(cant help the suiesiders)
[9/22/2004 8:54 AM] <Ajith> I think we discuseed this 20 mins ago :(
[9/22/2004 8:55 AM] <dasarathw> I think we sort of dealt with this right:(
[9/22/2004 8:55 AM] <Chinthaka> glen for the timebeing we got to implement the full DOM API on OM as we
need to support security
[9/22/2004 8:55 AM] <dasarathw> instanceof is a BAD practice
[9/22/2004 8:55 AM] <gdaniels> OK, so what do other ppl think about deployment parsing? DOM/JDOM OK,
or should we data bind?
[9/22/2004 8:55 AM] <chathura> :)
[9/22/2004 8:55 AM] <gdaniels> dasarath : instanceof is a bad practice only when inappropriate! :)
[9/22/2004 8:55 AM] <Ajith> finally on the right track :))))))
[9/22/2004 8:56 AM] <dasarathw> Accepted!
[9/22/2004 8:56 AM] <alek_s> i *like* to use instanceof ...
[9/22/2004 8:56 AM] <gdaniels> alek: me too!
[9/22/2004 8:56 AM] <dasarathw> and this is just one instance where instance of is a bad practice
[9/22/2004 8:56 AM] <alek_s> only DOM twists it to make it unnatural in Java ...
[9/22/2004 8:56 AM] <gdaniels> lol!
[9/22/2004 8:56 AM] <Srinath> back to deployment :)
[9/22/2004 8:56 AM] <alek_s> Dasarath: LOL ;-)
[9/22/2004 8:57 AM] <Ajith> can we jsut have a simple JDOm parser
[9/22/2004 8:57 AM] <Srinath> shall we go with DOM then /should it be JDOM
[9/22/2004 8:57 AM] <gdaniels> I need to take off in a couple of minutes...
[9/22/2004 8:57 AM] <Ajith> BTW have you guys seen XSTREAM thing
[9/22/2004 8:57 AM] -->| Jochen (~jwi@194.25.187.179) has joined #apache-axis
[9/22/2004 8:57 AM] <gdaniels> How about OM?
[9/22/2004 8:57 AM] <Jochen> Hi!
[9/22/2004 8:57 AM] <Ajith> we can use something like that too
[9/22/2004 8:57 AM] <gdaniels> Seriously, why don't we eat our own dog food here?
[9/22/2004 8:57 AM] <Srinath> OM to parse DD??
[9/22/2004 8:57 AM] <gdaniels> yes
[9/22/2004 8:58 AM] <Ias> Hi
[9/22/2004 8:58 AM] <gdaniels> if we make it easy to use, we should want to use it, no?
[9/22/2004 8:58 AM] <Srinath> well OM is DOM
[9/22/2004 8:58 AM] <Deeapl2> i think it is not required to use om to parse dd
[9/22/2004 8:58 AM] <gdaniels> I don't think it's required. I think it's good practice and proves
we've done a good job. :)
[9/22/2004 8:58 AM] <Ajith> Glen : yeah that is right but I guess we do not need an intermediate
Object model for DD's
[9/22/2004 8:58 AM] <gdaniels> If it's hard to use, we've built the wrong API. ;)
[9/22/2004 8:59 AM] <dasarathw> Well we sure cannot fine tune OM for everything...
[9/22/2004 8:59 AM] <Srinath> actually using OM we lose nothing + gain nothing
[9/22/2004 8:59 AM] <Ajith> we can just go ahead with it by pulling
[9/22/2004 8:59 AM] <Srinath> given that we done it right :)
[9/22/2004 8:59 AM] <Jochen> My question is this: Has anyone actually evaluated streaming? In
particular: Has anyone actually evaluated how OM and streaming play together?
[9/22/2004 8:59 AM] <Ajith> Srinath : excatly
[9/22/2004 8:59 AM] <Srinath> are we serouis on go for OM ???
[9/22/2004 8:59 AM] <gdaniels> We gain more test cases for OM, and we also gain NOT having to bring in
another API like JDOM.
[9/22/2004 9:00 AM] <Ajith> What I think is for now we can just use the pull parser and build the DD
object set right away
[9/22/2004 9:00 AM] <Ajith> and dont need any object model (such as DOM or JDOM in the process)
[9/22/2004 9:01 AM] <gdaniels> Sure, that seems fine too.
[9/22/2004 9:01 AM] <alek_s> Glen: i think using OM to parse DD will help to test it by ppl that knows
how to fix it :)
[9/22/2004 9:01 AM] <Deeapl2> alek: yep
[9/22/2004 9:01 AM] <alek_s> Jochen: i would liek to see this evaluated too
[9/22/2004 9:01 AM] <Srinath> my concern is it make the deployment development depends on the OM
[9/22/2004 9:02 AM] <alek_s> Jochen: however first would be to come up with some number of scenarios?
[9/22/2004 9:02 AM] <Srinath> in time line
[9/22/2004 9:02 AM] <Ajith> guys we can use something like this http://xstream.codehaus.org/
[9/22/2004 9:02 AM] <Deeapl2> no ?
[9/22/2004 9:02 AM] <alek_s> XStream is Java-XML binding tool
[9/22/2004 9:02 AM] <alek_s> i see no reason why it should not work well with OM?
[9/22/2004 9:03 AM] <gdaniels> I have to go, guys. Will leave my window open to catch the rest of the
log....
[9/22/2004 9:03 AM] <Ajith> yeah we can generate the objects starightaway by pulling right?
[9/22/2004 9:03 AM] =-= gdaniels is now known as glen-away
[9/22/2004 9:03 AM] <Srinath> bye glen .. see you next weeK
[9/22/2004 9:03 AM] <Ias> bye
[9/22/2004 9:03 AM] <Jochen> Alek: Use cases for using streaming?
[9/22/2004 9:03 AM] <Ajith> Glen : see ya
[9/22/2004 9:04 AM] <Srinath> anyhing else to address ?
[9/22/2004 9:04 AM] <alek_s> Jochen: yes - use cases that could be used to evaluate how streaming in OM
performs and is it easy to use
[9/22/2004 9:05 AM] <alek_s> Srinath: i thhink Jochen raised good points about support of streamin in OM
[9/22/2004 9:06 AM] <alek_s> i have a feeling that streaming in OM means lot of different things to
different people ...
[9/22/2004 9:06 AM] <dasarathw> +1 for that
[9/22/2004 9:06 AM] <Srinath> is not that differed prsing
[9/22/2004 9:06 AM] <Srinath> OM streaming = differed parsing
[9/22/2004 9:07 AM] <dasarathw> exactly
[9/22/2004 9:07 AM] <dasarathw> and that's why OM is using pull
[9/22/2004 9:07 AM] <Jochen> Alek: They are simple: a) Very much and similar requests b) Very large
response or request documents or c) very much response or request objects (b and c can be expressed as
unusually large body)
[9/22/2004 9:07 AM] <Srinath> alek jochen what do you think
[9/22/2004 9:07 AM] <Jochen> Srinath: It is not just that. Streaming also applies on the output side.
[9/22/2004 9:08 AM] <Srinath> did mean in serailizing
[9/22/2004 9:08 AM] <Srinath> please explan how seralizing can imporved
[9/22/2004 9:09 AM] <alek_s> Jochen: shouldnt in b) c) cases MTOM be used?
[9/22/2004 9:09 AM] <Jochen> My point is, that if an OM sits on top of a streaming model, then the
streaming model is open for use.
[9/22/2004 9:09 AM] <Jochen> Alek: MTOM?
[9/22/2004 9:09 AM] <dasarathw> Jochen: we are exposing the streaming API
[9/22/2004 9:09 AM] <alek_s> SOAP Message Transmission Optimization Mechanism
[9/22/2004 9:10 AM] <alek_s> gogle it but see for example:
http://www.w3c.org/TR/2004/CR-soap12-mtom-20040826/
[9/22/2004 9:11 AM] <alek_s> so in case ov *very* large body cotnent (such as 10s-100s of MBs) i would
use MTOM and optimzie it as attachments
[9/22/2004 9:11 AM] <alek_s> then worry about streaming of attachments
[9/22/2004 9:12 AM] <Jochen> dasarathw: Tell me more
[9/22/2004 9:12 AM] <dasarathw> sure
[9/22/2004 9:12 AM] <Jochen> Alek: But why the need for a different specification?
[9/22/2004 9:12 AM] <Jochen> Alek: I see no reason, why it shouldn't be possible without.
[9/22/2004 9:12 AM] <dasarathw> if one wants to use the pull API
[9/22/2004 9:13 AM] <dasarathw> he can access the pullparser wrapper
[9/22/2004 9:14 AM] <Srinath> OM has two interfaces ..Pull, DOM
[9/22/2004 9:14 AM] <dasarathw> but I heard that's not there in code yet
[9/22/2004 9:14 AM] <dasarathw> we have to update it
[9/22/2004 9:14 AM] <alek_s> Jochen: we need to stream XML into something and that something is
typically Java objects graph
[9/22/2004 9:14 AM] <Jochen> Alek: That is *your* use case. :-)
[9/22/2004 9:15 AM] <Jochen> Alek: My typical use case is thousands of XML documents.
[9/22/2004 9:15 AM] <alek_s> if XML input is large (>100MB) streaming will not help is you create as
large Java graph - you run out of memory anyway ...
[9/22/2004 9:15 AM] <alek_s> what in this case you do with each XML document?
[9/22/2004 9:15 AM] <Srinath> OM read the stream store as needed , user can get DOM or pull event from OM
[9/22/2004 9:16 AM] <dasarathw> or he can get it directly from the
[9/22/2004 9:16 AM] <dasarathw> parser wrapper and switch off caching
[9/22/2004 9:16 AM] <dasarathw> in OM
[9/22/2004 9:16 AM] <Ajith> yep
[9/22/2004 9:16 AM] <Jochen> Alek: Mostly storing (on input), query results on output
[9/22/2004 9:17 AM] <Jochen> dasarathw: This "switch off caching" thing I hear a lot. What does it
precisely mean?
[9/22/2004 9:18 AM] <Srinath> jochen:just read do not store
[9/22/2004 9:18 AM] <dasarathw> you pass the event directly to the user without
[9/22/2004 9:18 AM] <dasarathw> updating the OM table
[9/22/2004 9:18 AM] <Srinath> but what ever parsed is gone 4 good
[9/22/2004 9:18 AM] <dasarathw> once u switch off caching u cannot turn it on again
[9/22/2004 9:18 AM] <dasarathw> obviously
[9/22/2004 9:19 AM] <Jochen> dasarathw: Is the header "cached"?
[9/22/2004 9:19 AM] <dasarathw> unless they switch off caching yes
[9/22/2004 9:19 AM] <dasarathw> for OM
[9/22/2004 9:19 AM] <dasarathw> there is no difference b/w
[9/22/2004 9:19 AM] <dasarathw> header and body
[9/22/2004 9:20 AM] <dasarathw> the programmer
[9/22/2004 9:20 AM] <Srinath> heders chached all the time !!!
[9/22/2004 9:20 AM] <Jochen> dasarathw: I could live with that. How about the output side?
[9/22/2004 9:20 AM] <Deeapl2> any way when u come to provider default is chached off
[9/22/2004 9:20 AM] <Jochen> Srinath: Why so?
[9/22/2004 9:20 AM] <Srinath> jochen:what is the out put side
[9/22/2004 9:21 AM] <Jochen> Srinath: Serialization
[9/22/2004 9:21 AM] <dasarathw> u mean how we generate output with caching off
[9/22/2004 9:21 AM] <dasarathw> ?
[9/22/2004 9:21 AM] <chathura> think its because more than one handler mioght need the same headder right?
[9/22/2004 9:21 AM] <dasarathw> output is anyway going to be a new thing
[9/22/2004 9:21 AM] -->| Essington (~Essington@essington.user) has joined #apache-axis
[9/22/2004 9:21 AM] <Srinath> jochen:sorry SOAP need all the headers to deal with must understanding 1
[9/22/2004 9:21 AM] <Jochen> dasarathw: No, I mean, I would want the equivalent thing: Create a
response with absolutely no object tree in memory.
[9/22/2004 9:22 AM] <Srinath> serailization is java->XML conversion
[9/22/2004 9:22 AM] <Jochen> Srinath: That is something I don't believe. It may be true in *some*
cases, but not in all cases.
[9/22/2004 9:22 AM] <Jochen> Srinath: Ok, give me another word for generating the response.
[9/22/2004 9:22 AM] <Srinath> serializtion :)
[9/22/2004 9:23 AM] <dasarathw> Jochen: I don't think u can create an Object tree like that with the
current design
[9/22/2004 9:23 AM] <Jochen> dasarathw: The the design is broken. :-)
[9/22/2004 9:23 AM] <dasarathw> if I get u correctly,
[9/22/2004 9:23 AM] <chathura> ok guys i think i need to run
[9/22/2004 9:23 AM] <chathura> good night/day
[9/22/2004 9:23 AM] <Srinath> me too need to run ..
[9/22/2004 9:23 AM] <dasarathw> U want the same thing as lazy parsing
[9/22/2004 9:23 AM] <dasarathw> its a paradox here
[9/22/2004 9:24 AM] <dasarathw> because u are creating an object tree and
[9/22/2004 9:24 AM] <dasarathw> at the same time u do not want an in memory representation
[9/22/2004 9:24 AM] <alek_s> Guys i have started Wiki page about OM Use Cases
[9/22/2004 9:24 AM] <alek_s> http://wiki.apache.org/ws/FrontPage/Architecture/OMUseCases
[9/22/2004 9:24 AM] <Jochen> dasarathw: I do *not* want an object tree.
[9/22/2004 9:24 AM] <Srinath> :)
[9/22/2004 9:24 AM] <alek_s> Jochen and everybody: please record your concerns (including those raised
now about serialization etc.)
[9/22/2004 9:25 AM] <dasarathw> hmm
[9/22/2004 9:25 AM] <alek_s> direct XML processing with Java binding is good use case too :)
[9/22/2004 9:26 AM] <dasarathw> alek_s: about searching
[9/22/2004 9:26 AM] <Ias> alek_s: yes
[9/22/2004 9:26 AM] <dasarathw> we are thinking of building a binary tree
[9/22/2004 9:26 AM] <Jochen> Alek: Indeed :-)
[9/22/2004 9:26 AM] <Srinath> jochen can you put ur concerns in to set of wiki pages about OM at
http://wiki.apache.org/ws/FrontPage/Architecture
[9/22/2004 9:26 AM] <dasarathw> in OM
[9/22/2004 9:26 AM] <Srinath> you can find the link at the bottem
[9/22/2004 9:26 AM] <dasarathw> say how to impl getAttribute(String name)
[9/22/2004 9:27 AM] <Jochen> Alek, Srinath: I'll do my best. (Time consuming)
[9/22/2004 9:27 AM] <Farhaan> Alek: Shouldn't the use cases be addressed under requirements of OM on
the existing wiki page?
[9/22/2004 9:27 AM] <Srinath> :) thnks
[9/22/2004 9:27 AM] <dasarathw> what do u think hashmaps vs. binary trees
[9/22/2004 9:28 AM] <dasarathw> sequential searching is a starter
[9/22/2004 9:28 AM] <alek_s> Farhaan: they ar ebtoh linked from === XML stream processing with
SOAP:Body XML-Java binding
[9/22/2004 9:28 AM] <dasarathw> but we will need to move to a better way
[9/22/2004 9:29 AM] <Deeapl2> how we going to store data in b tree
[9/22/2004 9:29 AM] <Deeapl2> i mean in which format
[9/22/2004 9:29 AM] <Deeapl2> string as string or in diffrent manner
[9/22/2004 9:29 AM] <Farhaan> Alek: okay, will act as a requirement for both...that's fine
[9/22/2004 9:30 AM] <dasarathw> if its a btree
[9/22/2004 9:30 AM] <Srinath> all .. got to go bye
[9/22/2004 9:30 AM] <dasarathw> we will be storing object references
[9/22/2004 9:30 AM] <Deeapl2> hmmm
[9/22/2004 9:31 AM] <dasarathw> hay ppl
[9/22/2004 9:32 AM] <dasarathw> its 8.35 in SL
[9/22/2004 9:32 AM] <dasarathw> got to go!
[9/22/2004 9:32 AM] <Deeapl2> no one is talking its time to go
[9/22/2004 9:32 AM] <Ajith> yep we need to leave I guess
[9/22/2004 9:32 AM] <dasarathw> see u next week
[9/22/2004 9:32 AM] <alek_s> i have linked OM Use Cases and Requirements wiki pages
[9/22/2004 9:32 AM] <Deeapl2> bye all
[9/22/2004 9:32 AM] <alek_s> it is 9am here
[9/22/2004 9:32 AM] <Ajith> see yaaaaa
[9/22/2004 9:32 AM] <alek_s> bye
[9/22/2004 9:32 AM] <dasarathw> :)
[9/22/2004 9:32 AM] =-= YOU are now known as alek_away
[9/22/2004 9:32 AM] <dasarathw> yah
[9/22/2004 9:32 AM] <Farhaan> that's good alek.....got to go
[9/22/2004 9:32 AM] <Ias> bye
[9/22/2004 9:32 AM] <Deeapl2> bye
[9/22/2004 9:32 AM] <dasarathw> it will be 9.00am here in SL in no time
[9/22/2004 9:32 AM] |<-- Ias has left irc.freenode.net ("Chatzilla 0.9.64g [Mozilla rv:1.7.3/20040913]")
[9/22/2004 9:32 AM] <Farhaan> bye guys
[9/22/2004 9:32 AM] <--| chathura has left #apache-axis
[9/22/2004 9:32 AM] <dasarathw> that's my worry!
[9/22/2004 9:32 AM] <dasarathw> bye
[9/22/2004 9:32 AM] <--| Farhaan has left #apache-axis