[Axis2] Axis 2 chat log 10.02.2005

[Ajith Ranabahu <aj...@gmail.com>]

After a long time Glen joined the chat and continued a full 90 minute
conversation. The main things discussed were the issues with the
upcoming M1 release such as packaging, code cleanup and so on.


[09:04]  ***  Axis2 Weekly Chat
[09:04]  *** [freenode-info] why register and identify?  your IRC nick
is how people know you.  http://freenode.net/faq.shtml#nicksetup :
#apache-axis
[09:04]<Chinthaka> its 9.05 now :(
[09:05]<Ajith> should we start
[09:05]<Ajith> ?
[09:05]  *** gdaniels joined #apache-axis
[09:05]<gdaniels> hey folks
[09:05]<Ajith> Ho glen
[09:05]<gdaniels> sorry late - IRC problems
[09:06]<Ajith> I meant Hi :)
[09:06]<Srinath> Hi All :)
[09:06]<gdaniels> I was wondering where everyone else was until I
finally tried disconnecting and reconnecting :)
[09:06]<Srinath> Ajith has same prob?
[09:07]<Ajith> Yeah I also had to reconect
[09:07]<gdaniels> So how's it going over there?  Is everyone still
pretty much in shock, or are things starting to move again in Colombo?
[09:07]<Ajith> Glen : things are back in track I guess 
[09:08]<Ajith> mostly in Colombo
[09:08]<Srinath> for the costal areas it will take more time
[09:08]<gdaniels> *nod*
[09:08]<Chinthaka> yeah, poor our area :(
[09:09]<gdaniels> :(
[09:09]<gdaniels> Nature sucks sometimes.
[09:10]<Srinath> BTW where the impl packages should go?  :D
[09:10]<Ajith> Glen : BTW hows the review coming ?
[09:10]<gdaniels> Ajith: Slow. :(
[09:10]<gdaniels> I got a few more questions for here tho
[09:11]<gdaniels> Srinath: good q :)
[09:11]<gdaniels> I'm ok with either choice
[09:11]<Ajith> glen :  sure shoot them out
[09:11]<Srinath> me too :) but we got to pick one
[09:11]<gdaniels> it's nice when you have a lot of impls to have a
separate package, but it's a little heavy when you only have a few
[09:12]<Ajith> hmmm
[09:12]<gdaniels> i.e. it looks clean when the base package has
foo.Iface1, foo.Iface2 and foo.impl has Iface1Impl, etc
[09:12]<Chinthaka> This is what we have for OM now
[09:13]<gdaniels> Well, not really
[09:13]<Ajith> we are probably doing a similar thing
[09:13]<Ajith>  I guess
[09:13]<gdaniels> we have org.apache.axis.impl....
[09:13]<gdaniels> that's the bad part :)
[09:13]<Srinath> oh u mean put impl end of the classes at *impl*.*
[09:13]<Ajith> if not we can easily refactor to achieve that
[09:14]<Srinath> are we agreed there .. shall I reactor ? :)
[09:14]<gdaniels> Ajith: right, we're just deciding whether to have
om.OMElementImpl or om.impl.OMElementImpl (for instance)
[09:14]<gdaniels> I think I'm leaning towards om.impl....
[09:14]<Ajith> Om.impl seems to be more descriptive
[09:15]<gdaniels> ok, +1 for *.impl.*Impl
[09:15]<Ajith> so does this mean we have multiple impl packages
[09:16]<gdaniels> right
[09:16]<Ajith> ?
[09:16]<Ajith> and org apache axis imple vanishes
[09:16]<gdaniels> only put an impl package where it makes sense
[09:16]<Chinthaka> well, the initial idea was to put all impls under
org.apache.axis.impl
[09:16]<Srinath> one quick Q? how the llom and tableom fit in here?
[09:16]<gdaniels> Ajith: yes
[09:17]<gdaniels> depends on how you want to do it.
[09:17]<Chinthaka> *.impl.llom and *.impl.tom ?
[09:17]<Srinath> is it om.impl.llom.*
[09:17]<Srinath> k
[09:17]<gdaniels> Chinthaka: yeah
[09:17]<gdaniels> that works
[09:17]<Srinath> cool are we done there?
[09:17]<gdaniels> ok by me
[09:17]<Ajith> one thing that worries me is that imples are all over
the place if we do that
[09:17]<Chinthaka> Srinath : seems like yes ;)
[09:18]<gdaniels> Ajith: in most cases there aren't going to be
multiple implementations of our core classes
[09:18]<Ajith> hmm
[09:18]<gdaniels> That being the case, it's much easier to find them
when they're connected to the packages they implement
[09:18]<gdaniels> as opposed to in a completely different tree
[09:18]<Ajith> yeah you have a point
[09:19]<gdaniels> you don't find it a pain to navigate the
org.apache.axis.impl hierarchy and also all the other ones right now? 
I do.. :)
[09:19]<Srinath> ok 3 .2 . 1. 0 decided ;)
[09:19]<gdaniels> OK, Q - why is the Encoder thingy in there?
[09:19]<gdaniels> I thought we weren't going to do any data binding
stuff in M1 at all
[09:19]<Ajith> I was thinking whether we can have the discused
packaging but have a seperate source tree for that
[09:20]<Chinthaka> Ajith thats a good idea
[09:20]<Ajith> Anyway  I agree to the  curretn resolution
[09:20]  *** chathura joined #apache-axis
[09:20]<gdaniels> Ajith: for what?
[09:20]<Chinthaka> even there are some wsdl stuff
[09:20]<Chinthaka> which we don't need for this M1
[09:20]<Srinath> glen:encoding interace is there to able to write few
samples to show how encoding can do no top of M1
[09:20]<Srinath> and perf analysis
[09:21]<Chinthaka> Srinath : yes.
[09:21]<gdaniels> Hmmm.
[09:21]<Ajith> glen :  imean just like the test sources we have api
and impl source folders
[09:21]<Chinthaka> I think this was done thinking a bit of future :)
[09:21]<Srinath> we can leave it out of the M1 if needs
[09:21]<gdaniels> I'd prefer to see the other stuff stripped out, honestly.
[09:21]<gdaniels> It makes implications that things are baked when
they aren't yet
[09:22]<Chinthaka> Glen : +1
[09:22]<Ajith> BTW this seems to be decided now
[09:22]<Ajith> So I accept the current decision
[09:22]<gdaniels> Since that isn't "really" the way we're going to do
this stuff, let's wait until we have a real framework fo rit
[09:22]<Srinath> one Q? what happen to the serialization in the output path
[09:22]<Srinath> Object->SAX->OM
[09:23]<Srinath> or Object->SAX->stream
[09:23]<Chinthaka> Glen : shall we do this cleanup in a new place ?
[09:23]<gdaniels> Srinath: What file are you talking about?
[09:23]<gdaniels> i.e. where should I look to see what you mean?
[09:23]<Srinath> Encoder .. formally OutPutObject
[09:23]<gdaniels> Where does that get used right now?
[09:24]<gdaniels> (I thought M1 was just going to be about OM and
streams and push-writing)
[09:24]<Srinath> give a object to build OM or write it to the output stream
[09:24]<gdaniels> So all the examples would just build OM directly and
serialize it with no "object"s
[09:24]<Chinthaka> Glen : Yes
[09:24]<gdaniels> build OM directly, I mean
[09:25]<Ajith> well - push writer is what Srinath is taliking about
[09:25]<Chinthaka> but this ObectToOMBuilder was there to show the
flexibility :)
[09:25]<Srinath> yap glen it make it is impossibly to write a any
comparision with the other SOAP engines
[09:25]<gdaniels> Chinthaka: OK, so if you want to put it in samples/
that's fine
[09:25]<Chinthaka> Glen : Yeah
[09:25]<gdaniels> Srinath: We're not doing data binding yet
[09:25]<Chinthaka> I saw people asking abt encoding support in Axis 2
[09:26]<Srinath> if not databinding Object OM builder can not exsists in M1
[09:26]<gdaniels> If not what, Srinath?
[09:26]<Chinthaka> Srinath : we can put that in samples as Glen told
[09:26]<gdaniels> Explain more...
[09:27]<Srinath> shall we strip of all encoding stuff including object
to OM bilder
[09:27]<gdaniels> Srinath: +1 from me, for now
[09:27]<Srinath> we can have them in the src/test/***
[09:27]<Ajith> ooops
[09:28]<Chinthaka> Glen : there are some code under prototypeOne which
we don't want to go in to M1
[09:28]<Ajith> we have to make a serious refactoring for the code then
[09:28]<gdaniels> We're looking to get input from the community on the
direction this project is taking.  The more we put in that we're not
SURE about, the more people will waste time commenting on / needing to
understand those parts
[09:28]<Chinthaka> but will be needed after m1
[09:28]<Chinthaka> So where can we do this cleaning ?
[09:28]<Srinath> how about keep tham inside the src/test/** so the
samples still runs
[09:29]<Srinath> but src/java do not have any encoding stuff
[09:29]<gdaniels> Srinath: fine by me, but I'd prefer samples/
[09:30]<gdaniels> Chinthaka: that's a good question
[09:30]<Srinath> mm ...samples are do not added to classapth now ?
[09:30]<Chinthaka> We have two options 1. to have scratch --> M1 RC 2.
move the needed stuff to main src tree out of scratch area
[09:30]<gdaniels> or just scratch/M1
[09:30]<gdaniels> we don't have that yet, right?
[09:30]<Chinthaka> nope
[09:31]<Chinthaka> aren't we moving that to main src when we release
[09:31]<gdaniels> That's the other option.
[09:31]<Srinath> before go in to that shall we decide on the where the
encoding code goes?
[09:31]<gdaniels> But ESPECIALLY if we do that I want to make sure we
remove all the stuff that isn't solid yet
[09:31]<Chinthaka> yeah
[09:31]<gdaniels> Get the core parts really working right, and nothing else
[09:32]<gdaniels> Demonstrate the APIs are flexible and cool and fast,
and make it clear that the rest layers on TOP
[09:32]<gdaniels> (IMHO, of course)
[09:32]<Chinthaka> well, I think the XML in and XML out case (without
encoding) is what we aim in M1
[09:32]<gdaniels> +1
[09:32]<chathura> sounds good
[09:33]<Srinath> Hi All I like to see a one option for where the
encoding code goes .. not two?? that what happen to impl before?
[09:33]<Ajith> I was actaully thinking of an skeletaol axis
[09:33]<Chinthaka> Srinath, we can put those encoding stuff under
src/test i think for this M1
[09:33]<Ajith> where we have a working HTTP transport and most of the
code but at the "skeletol level"
[09:34]<Srinath> chinthaka:cool ..
[09:34]<chathura> i rather think encoding can become a sample rather than a test
[09:34]<gdaniels> I'd prefer not to put encoding code in this release
at all, Srinath.  But if you guys really want it, samples is
preferable to test for me.
[09:34]<Chinthaka> Chathura : what if both ;)
[09:34]<chathura> along with the other samples tht we r shipping
[09:35]<Srinath> chatura: have a look at the how the classapths are
set .. it bit tricky to put there
[09:35]<Srinath> glen: where at the samples?
[09:35]<gdaniels> Srinath: Why?
[09:35]<Ajith> Hmmm so we do need to keep the intefaces but just push
the impl out to samples
[09:35]<chathura> i know you are not building the samples right now but..
[09:35]<Chinthaka> Ajith ?????????
[09:36]<gdaniels> Incidentally, there should be more samples. :)
[09:36]<chathura> but we can change it
[09:36]<Srinath> glen: samples are build from a build file  for each
not compile by main build
[09:36]<Ajith> its like this :  we do have some outObject interface
and stuff that is being used in the code
[09:36]<gdaniels> Srinath: yes, and?
[09:36]<Srinath> yes already there are few .. plas have a look at the
sample dir :)
[09:37]<Chinthaka> Ajith, yes
[09:37]<Ajith> my Q is whether all these interfaces are stripped or
their impels only
[09:37]<Chinthaka> Ajith, I think both
[09:37]<Srinath> glen: now we have src/samples
[09:37]<Ajith> ????
[09:37]<Chinthaka> OutObject, its impl, ObjectToOMbuilder
[09:37]<Srinath> have encoding, deployment,general ... there
[09:38]<gdaniels> yup
[09:38]<Srinath> where exactly the encoidng code goes in the samples
[09:38]<gdaniels> is there a "baby step" sample that shows how to just
create an OM and serialize it?
[09:38]<gdaniels> Or to read an OM from an InputStream?
[09:38]<Srinath> Cahtura u r call?
[09:39]<gdaniels> Also, -1 to replicating org.apache.axis... package
structure inside each sample.  Why?
[09:39]<Srinath> sure enough
[09:39]<Srinath> :) me too
[09:39]<gdaniels> If you're a developer looking at samples, especially
a lot of them, you want a flatter hierarchy.
[09:40]  *** chathurah joined #apache-axis
[09:40]<Ajith> Glen : read the OM tutorial :)
[09:40]<gdaniels> sample1/src/sample1/ClassHere.java
[09:40]<Ajith> everything is clearly explained there
[09:40]<gdaniels> Ajith: OK
[09:40]<Srinath> sure glen, I will fix that package structure
[09:41]<gdaniels> Ajith: Doc looks great, btw!  I just haven't had a
chance to read it through yet
[09:41]<Srinath> where the encoding code gore in?
[09:41]<gdaniels> It doesn't. :)
[09:41]<Srinath> not in anywhere?
[09:41]<Srinath> :(
[09:41]<Ajith> oh ok
[09:42]<gdaniels> Honestly, that's my preference for M1.  But like I
said, I won't -1 putting it in as a sample.
[09:42]<gdaniels> "here's one way you could do this"
[09:42]  *** Chinthaka_ joined #apache-axis
[09:42]<Chinthaka_> hello
[09:42]<Deepal> glen : I sow some comments about deployment in ur mail
[09:42]<gdaniels> welcome back, Eran
[09:42]  *** Jaliya4925 joined #apache-axis
[09:42]<gdaniels> network troubles for you guys... :(
[09:43]<Deepal> regrding pull pasrsing
[09:43]<chathurah> ;(
[09:43]<gdaniels> Deepal: Yes, and Srinath responded in email
[09:43]<Chinthaka_> well, shall we decide on what packages are going in to M1
[09:43]<Chinthaka_> (coming back to earlier discussion :) )
[09:43]<Chinthaka_> and Glen : where to put the RC (Release Candidate)
[09:44]<gdaniels> I'm OK with putting it in the main src area
[09:44]<Deepal> as Srinath has said using OM it makes another object
strucure in memory
[09:44]<gdaniels> but we need to resolve packaging issues first
[09:44]<gdaniels> Deepal: so?  Deployment happens infrequently
[09:44]<gdaniels> A full object model is by far the easiest way to
parse this stuff
[09:44]<Chinthaka_> Glen : do u have any comments abt packages other
than the encoding stuff ?
[09:45]<Chinthaka_> I mean package structure 
[09:45]<gdaniels> the encoding stuff should go, the impl stuff should
be refactored, I'd prefer tests not to live in the same package as the
other classes
[09:46]<gdaniels> oh, and java/src is better than src/java
[09:46]<gdaniels> :)
[09:46]<Chinthaka_> Glen : didn't get the last point
[09:46]<Srinath> :)
[09:46]<Chinthaka_> the test thingy
[09:46]<Deepal> ok , first talk about packge structure and latter talk
aboout deploymnet :)
[09:46]<gdaniels> If you put tests parallel, you get:
[09:46]<Chinthaka_> Deepal : ;)
[09:46]<gdaniels> org/foo/Class1
[09:46]<gdaniels> org/foo/Class1Test
[09:46]<gdaniels> in the same directory
[09:47]<gdaniels> that makes it hard to clean out the tests from the
real classes
[09:47]<gdaniels> you need to do regexp matching and trust everyone to
name their tests correctly
[09:47]<Chinthaka_> in the same directory, after compiling only
[09:47]<gdaniels> right
[09:47]<gdaniels> I'm talking .class files here
[09:47]<gdaniels> (should have said that)
[09:47]<chathurah> ohh
[09:48]<Chinthaka_> ok
[09:48]<gdaniels> if they're in test.org.foo it's much easier
[09:48]<Srinath> glen:maven compile the test seperatly
[09:48]<Srinath> to test-classes
[09:48]<gdaniels> if they're in org.foo.test it's not that bad either
[09:48]<Chinthaka_> but this will make problems in testing private
methods, right ?
[09:48]<gdaniels> s/private/package/
[09:49]<Chinthaka_> ??
[09:49]<gdaniels> you can't test private methods from outside a given
class anyway, right?
[09:49]<gdaniels> you're talking about package-access methods
[09:49]<Chinthaka_> correct
[09:49]<Chinthaka_> we basically make them protected
[09:50]<gdaniels> it's true you can't test them unless you build tests
in the same package
[09:50]<Srinath> Hi glen, chinthaka with maven the test classes
compiled to differant package .. then regexp match is working cool
what ever you do?
[09:51]<Srinath> it do not pick wrong core clases
[09:51]<gdaniels> I'm just concerned about too much mechanism in the
build process.  Maven is dandy, but I guess I haven't totally bought
into it yet, and I want it to be easy to set this project up in an IDE
[09:51]<Srinath> it is easy ;)
[09:51]<Chinthaka_> u can use "maven idea" :)
[09:51]<Srinath> exactly
[09:51]<gdaniels> ?
[09:51]<Srinath> or maven eclipse
[09:52]<chathurah> ;)
[09:52]<gdaniels> that generates an IDEA project file?
[09:52]<Chinthaka_> yessss
[09:52]<Srinath> yap :)
[09:52]<Chinthaka_> thats what I do
[09:52]<gdaniels> cool!
[09:52]<Chinthaka_> even the *.iml file
[09:52]<gdaniels> What happens if you make changes?
[09:52]<gdaniels> Will it blow them away next time you run maven idea?
[09:53]<Chinthaka_> nope, u don't have to run it again and again
[09:53]<Chinthaka_> well, I will put an email on that ;)
[09:53]<Srinath> glen: if you change the classpath you have to run it agien 
[09:53]<Chinthaka_> to Axis-Dev
[09:53]<Srinath> but classapths are pretty stable :)
[09:54]<Chinthaka_> Srinath, do they ?? (kidding) ;)
[09:54]<Srinath> well :D
[09:54]<gdaniels> OK, then - separate classes directory for tests it is then
[09:54]<gdaniels> I'm still a little dubious but I'm willing to be convinced
[09:55]<Chinthaka_> well, i'd like to see a decided packges structure
after this chat, so that we can move to src
[09:55]<Srinath> maven do it automatically .. that is the default conf
[09:55]<gdaniels> we need to see the refactored impl stuff first
[09:55]<Chinthaka_> ok, so then shall we do that in scratch
[09:55]<Srinath> with the encoding strip off
[09:55]<Chinthaka_> I will create the folder M1 RC folder under scratch
[09:55]<gdaniels> and we should expect refactoring one or two times
even after we move to real src/ :)
[09:55]<Deepal> then how about wsdl stuff
[09:56]<Deepal> i mean thing that we are not going to ues
[09:56]<Chinthaka_> Glen : Agreed and expected :D
[09:56]<gdaniels> Chinthaka_: You don't need the RC part
[09:56]<gdaniels> RC is about the timing, not about the directory name
[09:56]<Chinthaka_> ok :|
[09:56]<gdaniels> RC is an SVN label, in other words
[09:57]  *** dasarath quit FreeNode : Remote closed the connection
[09:57]<gdaniels> Deepal: What WSDL stuff?
[09:57]  *** chathura quit FreeNode : No route to host
[09:57]  *** Chinthaka quit FreeNode : No route to host
[09:57]<Srinath> ppl one last bugging ... if it is not criticla shall
we keep the encoding stuff in the src/test/** toherwise half of the
test cases will disapper
[09:57]<gdaniels> (clearly I haven't made it through all the code yet!)
[09:57]<Deepal> there are some wsdl code that we are not using in M1
[09:57]<chathurah> ok its the WOM buider code
[09:57]<gdaniels> Srinath: Half the test cases test the ENCODING STUFF?
[09:57]<Deepal> like wom builder
[09:58]  *** Jaliya quit FreeNode : Read error: 113 (No route to host)
[09:58]<gdaniels> Deepal: Pull it out. :)
[09:58]<Srinath> geln: withpout encoidng there are not many test cases
that you can write
[09:58]<chathurah> i am working on , its  in progress so we thought of
leaving it out for m1
[09:58]<Srinath> expect echo a OMElemnt
[09:58]<gdaniels> Srinath: Why is that?
[09:58]<gdaniels> You can test namespaces, XML serialization and
deserialization, SOAP structure....
[09:59]<gdaniels> MustUnderstand attributes, Roles, etc....
[09:59]<gdaniels> Building and dissecting XML trees
[09:59]<gdaniels> And you can write test services/clients which dig
into the data themselves
[09:59]<Srinath> :) When we send 1000 array of struct + profiling +
perf analysis it put the code in to real test
[10:00]<Srinath> we have allmost all you menation + more :)
[10:00]<gdaniels> But it's not a real test unless the code is real
[10:00]<Srinath> it test how the OM build, serialize, switches from
tree to stream
[10:00]<gdaniels> In other words, if the test is about turning a 100
element Java array into XML, it's NOT A REAL TEST until it's actually
testing the real serialization code
[10:01]<gdaniels> If the test is about building a 100 element XML
document with OM, then it's a real test. :)
[10:01]<gdaniels> see what I mean?
[10:01]<Srinath> java array elements broken down to the xml it is  areal test
[10:02]<gdaniels> The serialization code can be part of a test as an
example of how to build OM, but I just don't want to imply we have
data binding working
[10:02]<Srinath> my point is it is easy to write test case with soem
kind of encodign support
[10:02]<gdaniels> It's not hard even without it
[10:03]<gdaniels> ...or rather it's not hard if you put it in the test
itself instead of in the framework
[10:04]<gdaniels> So what do others think?
[10:04]<gdaniels> Should we take this to a vote on the mailing list,
maybe, let everyone chime in?
[10:04]<Srinath> My self and Ajtith find a lot of bugs (e.g OM do not
switch to the stream and fix it) while trying encoding test
[10:04]<Srinath> I do not see otheer convetional test cases cover them
[10:05]<gdaniels> Srinath: I'm not saying it's bad to have this kind
of code around to play with.  I'm saying it's bad to imply that we
have part of the system working when it hasn't really been designed +
built yet.
[10:05]<Chinthaka_> Glen : agreed
[10:05]<gdaniels> When we talked M1 originally we talked about no data binding
[10:06]<gdaniels> So that's why I was surprised to see it in there
[10:06]<Chinthaka_> And I think its better to put this up in the mailing list
[10:06]<Srinath> any voleneeers to try to simulate simpler powerful
test without using the encoding ?
[10:06]<Srinath> simpler = similer
[10:07]<gdaniels> Sure!
[10:07]<Srinath> ok :)
[10:07]<gdaniels> So by powerful == large documents?  Or do you mean
something else by that?
[10:08]<gdaniels> I'll take a look at what's there in any case.
[10:08]<Srinath> I want all senarion e.g. OM should switch from OM to
stream .. bit of perf and load testing
[10:08]<gdaniels> point me at a test I should look at in particular?
[10:09]<Srinath> org.apache.axis.encoding.EchoTest
[10:09]<gdaniels> Cool
[10:09]<Srinath> also look at the src/samples/encoding/sample1
[10:09]<gdaniels> Just noticing OM stuff - 
[10:09]<Srinath> that two is conntected
[10:09]<gdaniels> we should have factory.createOMElement(QName)
[10:10]<Srinath> +1
[10:10]<Chinthaka_> I added it yesterday
[10:10]<gdaniels> and factory.createOMElement(localname), maybe
[10:10]<Chinthaka_> createOMElement(localName, nsURI, nsPrefix)
[10:10]<gdaniels> Chinthaka_: no, I mean javax.xml.namespace.QName
[10:11]<Chinthaka_> ok, consider it done :)
[10:11]<gdaniels> it should do the work for you without you splitting
the QName apart
[10:11]<Chinthaka_> didn't get that past past
[10:11]<Chinthaka_> part
[10:11]<gdaniels> plus we should prolly have just (localName) and
(localName, namespaceURI) versions
[10:11]<gdaniels> to let it decide prefixes for you
[10:12]<Chinthaka_> hmm
[10:12]<gdaniels> Chinthaka_:  Was just saying that you could split
QName yourself into localName/URI/Prefix but the API should let you
just pass the QName
[10:12]<Chinthaka_> yeah, gotcha
[10:12]<gdaniels> So back to deployment?
[10:12]<Deepal> k.
[10:12]<gdaniels> And we'll take the encoding/packaging discussion to the list?
[10:13]<Srinath> sure :)
[10:13]<gdaniels> ok
[10:13]<Srinath> yap 
[10:13]<Chinthaka_> well, shall we create M1 
[10:13]<Chinthaka_> with the decisions made here ?
[10:13]<Deepal> so glen for the M1 cant we keep those as it is 
[10:13]<gdaniels> depends on how you think about it, Deepal.
[10:13]<Deepal> and change that latter , I mean moving from pull parser to Om
[10:14]<Srinath> glen: what do you think about Stax parsing given
algorithm improved
[10:14]<gdaniels> Why are we doing a "release" at all, instead of
saying "hey come look at the SVN tree, we're working on stuff"?
[10:14]<Srinath> glen:marketting point of view realse have a value :)
[10:15]<Srinath> we tell come and look ath three all the time
[10:15]<gdaniels> I mean, I know everything is subject to change and all, too.
[10:15]<gdaniels> Yup
[10:15]<Srinath> yap glen everything .. (in this world)  :D
[10:16]<Ajith> Glen : but a release has a marketing values (and an
opportunity to make some noise ) :D
[10:16]<gdaniels> We can leave it as is, but it seems less clean and
more repetitive than it needs to be
[10:16]<gdaniels> But if you make noise and people come look and don't
like what they see enough, they tend to not be as easy to get back
next time
[10:16]  *** alek_away joined #apache-axis
[10:16]<Ajith> hmmmm
[10:17]<Srinath> I agree ..are not we have someting to make them happy
[10:17]<gdaniels> We want to have something to make them happy, exactly.
[10:17]<Srinath> sure :)
[10:17]<Chinthaka_> how abt having another chat before next wednesday
[10:17]<Srinath> Alek need a favour   .. about u r bench mark
[10:18]<gdaniels> I just think there are areas where we could use some
refactoring/cleanup, and that's one of them
[10:18]  *** alek_away is now known as alek__s
[10:18]<alek__s> hello everybody
[10:18]<alek__s> yes
[10:19]<gdaniels> Chinthaka_ : Sure, if we can find a time
[10:19]<gdaniels> Hi Alek
[10:19]<Chinthaka_> how abt next Monday
[10:19]<Srinath> Alek:where is the most recent copy of u r benchmark? :)
[10:19]<Chinthaka_> this time ?
[10:19]<alek__s> the version that we used for tests is on the webpage
[10:19]<gdaniels> I've got to get up early and present at a conference
on Tuesday, so Mon night is bad for me. :(
[10:19]<alek__s> we are preparing new version that has more of comlpex
types, more realistic web services (like google) etc
[10:19]<Srinath> http://www.extreme.indiana.edu/xgws/soap_bench/??
[10:20]<alek__s> but it is nto yet ready
[10:20]<alek__s> that should be it
[10:20]<Chinthaka_> or Sunday ?
[10:20]<alek__s> if you run into any problems send me email
[10:20]<gdaniels> I could do Sun night this time (Mon morning for you)
[10:20]<gdaniels> Let's run it by on the list - can you send an email
asking for +1's/-1's?
[10:20]<Chinthaka_> Glen : oki, thats great
[10:20]<Ajith> that seems to be fine
[10:20]<Srinath> sure Alek; what should I do to make it workon the Axis2?
[10:22]<alek__s> just take bechmark wsdl file
[10:22]<alek__s> generate whatever you need ot generate (skeletons?)
[10:22]<alek__s> and implement service
[10:22]<alek__s> then run banhmark client agains axis2 service
[10:22]<Ajith> ok
[10:22]<Srinath> cool
[10:22]<alek__s> i think we have online code for axis 1.2 so that
should show what was doen
[10:23]<alek__s> it is all pretty easy and wsdla has just few simple datatypes
[10:23]<Srinath> exactly
[10:23]<Srinath> :)
[10:23]<Ajith> Cool 
[10:23]<Srinath> yap actually I see it
[10:25]  *** Deepal quit FreeNode : Read error: 54 (Connection reset by peer)
[10:25]<gdaniels> So "generate" here means "read the WSDL and write
the right code" :)
[10:25]<Chinthaka_> sent an email to dev list asking for a chat on Sunday
[10:25]<Srinath> yap I have been doing it for few days :D
[10:25]<Srinath> manual geeration ;)
[10:25]<gdaniels> Ahh, just like the good old days of 2001 :)
[10:26]<chathurah> ;)
[10:26]<Chinthaka_> ;)
[10:26]<gdaniels> ok, guys, I unfortunately need to run :(
[10:26]<Ajith> sure
[10:26]<Chinthaka_> and i think the time is up too :)
[10:26]<alek__s> that could probably be autoamted with little effort
when using reflection and dynamic proxy
[10:26]<Ajith> I gues I also need some tea :)
[10:26]<alek__s> the only thing needed nowadays to generate is just
java interface
[10:26]<gdaniels> Great talking, sorry I've been so swamped lately,
and nice job on moving things forward!  I don't mean to be a hardass,
I'm just really concerned about getting this stuff right.
[10:27]<Srinath> :) we know glen
[10:27]<Srinath> thanks
[10:27]<gdaniels> Oh incidentally
[10:27]<alek__s> i hope somebody send chat lot
[10:27]<alek__s> og
[10:27]<alek__s> log
[10:27]<gdaniels> If folks hang out on this channel when they're
around that's probably a good thing
[10:27]<Ajith> Glen : yeah we understand what you mean . and you are
absolutrely right on having things right
[10:28]<gdaniels> I'll try to start doing that myself
[10:28]<Ajith> yaeah I think I can
[10:28]<gdaniels> esp near releases it can be handy (IM too)
[10:28]<gdaniels> (this is easier to have group talks in tho)
[10:28]<gdaniels> OK - Have a great day/night folks :) :)
[10:28]<Srinath> sure actually am haning there alone most of the time :)
[10:28]<gdaniels> :) We'll fix that Srinath.  Night!
[10:29]<Srinath> bye :)
[10:29]  *** gdaniels quit FreeNode : 

-- 
Ajith Ranabahu