axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject [Axis2] IRC chat log 2004-09-22
Date Wed, 22 Sep 2004 14:40:44 GMT
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

Mime
View raw message