You need to go through the checkin freeze and test cycle if you want 1.1 to be a stable release for the next couple of months, while new major features are integrated into the codebase. Doing a beta will get substantially more users to try out the code and make for a much more stable 1.1.
- Dennis
Glen Daniels wrote:
Hi folks!
Here's the chat log for today.
--Glen
Session Start: Tue Nov 26 11:29:59 2002
[12:52] *** kameshwar has joined #ApacheAxis
[12:53] <kameshwar> hi all
[12:54] <davanum> Hi kamesh
[12:55] <kameshwar> I had sent a mail to the list askign about the future of the Async support
[12:55] <kameshwar> in Axis
[12:55] <kameshwar> I got a reply from James that it is a work in progress
[12:56] <davanum> yes. That sounds right.
[12:56] <kameshwar> Just wanted to when would that be made avbl in the Axis release?
[12:56] <Essington> kameshwar: what is meant by Async support?
[12:56] <kameshwar> Asynchronous Messaging support [12:56] <Essington> :-) yes . . .
[12:57] <davanum> Kamesh: No dates yet on anything yet...
[12:57] <kameshwar> oh ok
[12:57] <Essington> so the request message and response message are two separate events?
[12:57] *** GlenLunch is now known as GlenD
[12:57] *** DaveChapp has joined #ApacheAxis
[12:57] <davanum> hi glen
[12:57] <davanum> hi dave
[12:57] <GlenD> hola dims, folks!
[12:57] <kameshwar> Hi glen
[12:57] <DaveChapp> Hola!
[12:58] <kameshwar> Hi dave
[12:58] <DaveChapp> Hi
[12:58] <GlenD> Thanks for coming - let's give it a few more mins before launching in to let any others show up
[12:58] *** tom_lunch is now known as tjordahl
[12:59] <DaveChapp> Jaime is on his way.....
[12:59] *** JaimeMeri has joined #ApacheAxis
[12:59] <JaimeMeri> Hi all [12:59] <davanum> hi Jaime
[12:59] <GlenD> hi Jaime
[13:00] <DaveChapp> Hi Jaime
[13:04] <GlenD> allllrighty then
[13:04] <GlenD> it's 5 past, maybe let's get started?
[13:04] <tjordahl> yup
[13:05] <GlenD> So what should we discuss first? Bugs, 1.1, async, schema...?
[13:05] <GlenD> I vote 1.1, which leads inevitably into bugs :)
[13:05] <davanum> Bugs First...
[13:05] <davanum> too many of them :(
[13:06] <GlenD> Indeed.
[13:06] <tjordahl> Someone should fix them all
[13:06] <GlenD> Fix them all, fix them well.
[13:06] <GlenD> Good luck, Tom!
[13:06] <GlenD> OK, next topic.
[13:06] <GlenD> :)
[13:06] <davanum> AND write test-cases...
[13:07] <GlenD> I like the test-case-first idea, even.
[13:07] <davanum> Glen: Can you take care of the EjbProvider patch Bug #14671?
[13:07] <GlenD> If we made it super easy to write a test case, in fact, we could actually ask bug submitters to attach them to the bugzilla reports....
[13:07] <GlenD> dims: yes.
[13:08] <GlenD> I was going to suggest that we actually try for a conference call next Tuesday at which we can do a bug scrub / assignment
[13:08] <davanum> +1 to conf call.
[13:08] <GlenD> In the interim we can all take responsibility for becoming familiar with the list, and picking bugs we'd like to handle
[13:08] <GlenD> we can do some of this via email beforehand, and then plow through on the call
[13:08] <GlenD> what do the rest of y'all think?
[13:08] <davanum> sounds good...
[13:09] <tjordahl> Who is going to be able to fix bugs? Glen, Dims and ???
[13:09] <GlenD> Dave, Jaime, would you guys be into helping out for bugs that don't require in-depth Axis knowledge?
[13:09] <tjordahl> No Russell, Rich, Richard, etc, etc
[13:10] <tjordahl> No Sam either....
[13:10] <GlenD> Tom: Yeah, but who knows - we might be able to rope them in for next week.
[13:10] <JaimeMeri> Sure that would be fine with me [13:10] <tjordahl> That would be great.
[13:10] <GlenD> And it doesn't have to be just committers, either.
[13:10] <DaveChapp> Yup.
[13:10] <JaimeMeri> That's good because I'm not a committer [13:10] <GlenD> If other folks are psyched (hint hint), they can take bugs, fix them and submit patches, and then BECOME committers...
[13:10] <JaimeMeri> :) [13:10] <GlenD> :)
[13:10] <davanum> :)
[13:10] <kameshwar> great :)
[13:10] <DaveChapp> 8-)
[13:11] <GlenD> OK. So, everyone should please read over the bug list.
[13:11] <davanum> OK.
[13:11] <GlenD> If you see a bug that is clearly in your zone of expertise / comfort, assign it to yourself.
[13:11] <JaimeMeri> k [13:11] <tjordahl> Schedule for 1.1 and release manager?
[13:12] <GlenD> Next week we'll schedule a call and go over the list and see where we're at.
[13:12] <davanum> Schedule: How about before christmas?
[13:12] <GlenD> Criteria for 1.1 first, maybe. Are we good with releasing the current codebase, or should we wait for the bug scrub?
[13:12] <GlenD> Oh, before Xmas should be OK, I would think.
[13:13] <GlenD> I can release manage.
[13:13] <davanum> Glen: I think we should bring down the bug count to around 60-70...
[13:13] <tjordahl> Do we need a beta or RC? OR shuld we just cut a 1.1 and ship it.
[13:14] <davanum> Cut 1.1 directly.
[13:14] <GlenD> I think we can just cut 1.1 and ship it when we think it's ready, personally.
[13:14] <GlenD> We can always do a 1.2 (release early and often)
[13:14] <davanum> yep. [13:14] <DaveChapp> What's the rush to get it out before XMas?
[13:14] <GlenD> Holiday shoppers.
[13:15] <GlenD> Oh, wait....
[13:15] <GlenD> "The perfect gift for your Java geek friends!"
[13:15] <davanum> Dont' want 3 months before releases...
[13:15] <GlenD> Seriously, I think before the end of the year would be nice, and that means before XMas, realistically.
[13:16] <tjordahl> It would sync up with some stuff interally. But mainly its to get users using a bug fixed release post-1.0
[13:16] <DaveChapp> Always a good idea. Nobody dares to use a 1.0 product.
[13:16] <tjordahl> There is alrady lots of stuff we are telling people to check in the nightly's.
[13:16] <tjordahl> (Faults, doc/lit WSDL, headers, etc)
[13:16] <GlenD> Plus that servlet thingy
[13:16] <davanum> Remember we need to run TCK Test Harnesses again :(
[13:17] <GlenD> good reasons to ship soon
[13:17] <GlenD> yup
[13:17] <tjordahl> Did Sam every get that automated and passing?
[13:17] <tjordahl> s/every/ever/
[13:17] <davanum> Not that i know of...
[13:17] *** JamesMSne has joined #ApacheAxis
[13:17] <JamesMSne> greetings all
[13:17] <davanum> Hi James
[13:17] <GlenD> hi James
[13:17] <DaveChapp> Hi James
[13:18] <kameshwar> Hi James
[13:18] <JamesMSne> so... we're talking about 1.1 release?
[13:18] <davanum> yep, before XMas...
[13:18] <GlenD> so we're generally aiming for end of year, and this will be informed by the bug scrub.
[13:18] <JaimeMeri> hi james [13:18] <JamesMSne> that would be a good thing
[13:19] <tjordahl> JAmes, can you help out on the bug scrub?
[13:19] <JamesMSne> should be able to.
[13:20] <JamesMSne> won't be able to start until next week
[13:20] <JamesMSne> but I could take some of the items
[13:20] <GlenD> (the plan for which is "everyone read the bug list this week, then conference call next Tuesday to run down and assign things / see where we're at")
[13:20] <JamesMSne> that works
[13:20] <GlenD> OK. Anything else re: 1.1?
[13:21] <JamesMSne> we'll keep the ime stuff out of 1.1
[13:21] <kameshwar> oh :(
[13:21] <GlenD> +1, but we should resolve it soon thereafter
[13:21] <kameshwar> i thought that would be in 1.1 :)
[13:21] <JamesMSne> let's target the first release of ime and the transports for 1.2
[13:21] <GlenD> sounds good to me
[13:21] <DaveChapp> +1
[13:21] <davanum> +1
[13:21] <GlenD> Speaking of which, shall that be our next topic?
[13:21] <JamesMSne> xmas is a bit quick to do a good bug scrub and test [13:21] <JamesMSne> glen: that works
[13:22] <GlenD> You may be right, James. If that's the case we'll decide whether or not to push back 1.1 depending on the severity of the current issues.
[13:22] <JamesMSne> k
[13:22] <GlenD> So - IME stuff
[13:22] <tjordahl> I think we have fixed enough stuff and added some functionality (faults, headers, WSDL fixes) to warrent getting it sooner rather than later.
[13:23] <GlenD> (I agree Tom)
[13:23] <tjordahl> (That was for James' benifit)
[13:23] <JamesMSne> tom: ok
[13:24] <JamesMSne> so... ime stuff... what's on your mind glen? want me to give a quick overview of status then discuss issues?
[13:24] <GlenD> I had some questions. First off, I'd punt the FeatureEnabled interface - it doesn't do anything at present, and I don't think that's the right model for this stuff (I've been working on Features/Modules/Bindings in my sandbox)...
[13:24] <GlenD> I think we should discuss that architecture separately.
[13:24] <JamesMSne> ok
[13:25] <JamesMSne> I agree that it can be punted for now, but I really want to revisit
[13:25] <GlenD> Second, why is MessageCorrelator not just an interface with a matches(MessageCorrelator) method?
[13:25] <GlenD> +1, definitely! I have a lot of ideas in this area, I just think they're sort of separate and shouldn't get mushed in with async.
[13:25] <JamesMSne> wanted to provide a simple base that can be used as is
[13:25] <GlenD> It just seems incongruous with everything else being interfaces, is all.
[13:25] <GlenD> Not a big deal, just an architectural weevil.
[13:25] <JamesMSne> we could make MessageCorrelator an interface, and in org.apache.axis.internal we could create a SimpleMessageCorrelator
[13:26] <JamesMSne> adding a matches(MessageCorrelator) method is a good idea
[13:26] <JamesMSne> jaime: thoughts on that?
[13:27] <JaimeMeri> James: No complaints here. It makes sense [13:27] <GlenD> Seems like that's exactly what you DO with Correlators... :)
[13:27] <JamesMSne> :-)
[13:28] <JamesMSne> ok, that's added to my todo's
[13:28] <GlenD> receive(MessageExchangeEventListener)
[13:28] <GlenD> that seemed weird to me too.
[13:28] <JaimeMeri> Glen: Receive should probably return the received message [13:29] <GlenD> I understand the other receive()s
[13:29] <JamesMSne> glen: why is it wierd?
[13:29] <GlenD> but the one which just takes a MessageExchangeEventListener seems odd. What's the difference between that and setMessageExchangeEventListener()?
[13:31] <JamesMSne> hmm... I thought I had removed the getter and setter. My preference is to specify listeners per send/receive so that state is not a factor
[13:31] <GlenD> um
[13:32] <GlenD> What's the relationship between a MessageExchange and a MessageContext? Let's start there.
[13:32] <JamesMSne> I'm not sure that sentence made sense... (sorry, trying to do two things at once)
[13:32] <JaimeMeri> James: I think it is pretty convenient to be able to set a listener for all messages [13:32] <GlenD> (no it made sense, but I'm not sure I grok the architecure yet)
[13:32] <JamesMSne> MessageExchange is the interface through which MessageContexts are passed back and forth
[13:32] <JamesMSne> e.g. MessageExchange.send(MessageContext)
[13:33] <JamesMSne> MessageExchange.receive(MessageExchangeEventListener) says "deliver the message to the specified listener"
[13:33] <GlenD> so a MessageExchange is "a thing I want to deal with messages for me"
[13:33] <GlenD> gotcha
[13:34] <JamesMSne> jaime: I agree that it's convenient, I just don't think it's necessary
[13:34] <JaimeMeri> James: Do you think that the listener implementation will change very often? [13:34] <JamesMSne> no
[13:35] <GlenD> Can you have multiple listeners?
[13:35] <JaimeMeri> So then specifying a default listener makes sense [13:35] <JamesMSne> although someone may want to specify a new listener for individual messagecorrelators
[13:35] <JamesMSne> new listener instance that is
[13:35] <JamesMSne> glen: yes
[13:36] <JaimeMeri> So you could support a default listener and a set of methods that allow you to override the default on a per-invocation basis [13:36] <GlenD> +1
[13:36] <JamesMSne> the way it is currently set up, the MessageExchange can use a single listener for all requests or pass in an override for each request
[13:36] <JamesMSne> jaime: +1
[13:37] <JamesMSne> yeah, what you just said :-)
[13:37] <GlenD> although... I'm not sure we need the complexity of multiple listeners yet. What if we just restricted it to one-per ME for now?
[13:37] <GlenD> That would simplify the internal code a good bit, and then we could always add more later if there's demand.
[13:38] <JamesMSne> actually, it doesn't add any real complexity
[13:38] <JamesMSne> a minor if/then switch
[13:38] <GlenD> well, it might, actually, in terms of understanding what's going on.
[13:39] <GlenD> It seems to me the important part about this is breaking the coupled synchronous pipe we have now into pieces. But it's still a linear set of pieces with looser coupling.
[13:39] <GlenD> Once you add the ability to fan-in/fan-out, it can get weird.
[13:39] <GlenD> It's powerful, no doubt, but maybe that should be considered a second step.
[13:40] <GlenD> Does that make sense?
[13:40] <JamesMSne> hmm.. I personally still don't see any problem with it. will have to think about it
[13:40] <JaimeMeri> I agree with Glen. The per invocation override is still possible if you use the receive methods when you want to handle particular messages differently [13:40] <DaveChapp> Once we tack a client API on that, we would want to bubble up that multiple listener capability to the API, right?
[13:40] <GlenD> (although I was going to go as far as to say you shouldn't even need to do that)
[13:41] <JamesMSne> dave: perhaps
[13:41] <JaimeMeri> Dave: Client API listeners do not necessarily map 1-1 with ME listeners [13:42] <kameshwar> can we find a real time use case to see if we need multiple listener?
[13:42] <JamesMSne> possible scenario: multiple clients may use a single ME
[13:42] <JamesMSne> each client may use a different listener
[13:42] <GlenD> James: flesh that out
[13:42] <GlenD> Give me a real scenario.
[13:43] <GlenD> Multiple clients, at present, do NOT share AxisEngines, nor should they according to the Axis design.
[13:44] <JamesMSne> ok, then multiple HttpSession using the same AxisServer instance
[13:44] <JamesMSne> HttpSession == a client request on the AxisServlet
[13:44] <JamesMSne> eventually, communication with the AxisServer will happen through the ME interface
[13:44] <GlenD> hm.
[13:45] <GlenD> well, so maybe this is a place where I disagree with the design then.
[13:45] <kameshwar> James:Can we one more implementaion of MessageListener called ForkMessageListener which has a list of MessageListener internally it can send/receive?
[13:45] <GlenD> it seems like MessageContext is already about a particular flow through the system. So I'd do it with that.
[13:45] <JamesMSne> btw, I'm just throwing stuff out to see if it makes sense.... I'm not necessarily advocating anything
[13:46] <GlenD> i.e servlet creates a MessageContext, and *that* has the configuration for correlating, events related to that message, etc... then it just hands that to the shared server instance.
[13:46] <JamesMSne> kameshwar: I'd say that adds a bit more complexity that we need right now
[13:46] <kameshwar> ok
[13:46] <JamesMSne> glen: thinking
[13:46] <GlenD> MessageContext context = <same stuff we currently do>
[13:47] <GlenD> context.setEventListener(me);
[13:47] <GlenD> engine.invoke(context);
[13:47] <GlenD> or something like that
[13:47] <JamesMSne> engine.getMessageExchange().send(context);
[13:47] <GlenD> well, I'm calling into question whether we need MessageExchange.
[13:48] <JamesMSne> yes, think about receive only operations
[13:48] <JamesMSne> engine.getMessageExchange().receive(listener);
[13:48] <JamesMSne> without any initial invocation
[13:48] <JamesMSne> e.g. client wants to pull a soap message off a JMS queue
[13:48] <GlenD> thinking
[13:49] <GlenD> client wants to pull a message from a queue.
[13:49] <kameshwar> James:In that use case how would the MessageExchange be configured to attach itself to the JMS Queue?
[13:49] <JamesMSne> also, client wants to do send now, then receive later (not as a callback)
[13:49] <GlenD> OK, is this message a response to something?
[13:49] <JamesMSne> MessageExchange.send(context);
[13:49] <JamesMSne> no
[13:49] <GlenD> what is it?
[13:50] <JamesMSne> notification
[13:50] <GlenD> an event notification or something?
[13:50] <GlenD> ok
[13:50] <JaimeMeri> Kameshwar: The JMS trasnport would be an implementation of MessageExchange. [13:50] <JamesMSne> kameshwar: the config for the JMS transport would have the JMS connection info
[13:51] <JamesMSne> invoke assumes request/response
[13:51] <JamesMSne> we need separate send/receive operations
[13:51] <JamesMSne> that's where MessageExchange comes in
[13:51] <GlenD> invoke() doesn't actually assume that
[13:52] <GlenD> call.invoke() does. But AxisClient.invoke() doesn't.
[13:52] <JaimeMeri> Glen: It does assume the generation of an outbound request though doesn't it? [13:52] <GlenD> Not necessarily.
[13:52] <JamesMSne> ??
[13:52] <JamesMSne> you must provide an input MessageContext
[13:52] <JaimeMeri> I guess it is up to your transport implementation and what the pivot actually does [13:53] <JamesMSne> that seems like a hack to me
[13:53] <GlenD> James: yes, that's true, but it's not necessarily an "input" messagecontext. It's just a set of properties 'n stuff.
[13:53] <JamesMSne> a big hack
[13:53] <GlenD> What seems like a hack?
[13:53] <JamesMSne> using invoke
[13:54] <JaimeMeri> James: I agree, the use of receive and send is a lot more intuitive [13:55] <GlenD> Let me back up. There is going to be a MessageContext associated with any sending or receiving that happens.
[13:55] <GlenD> Agreed?
[13:56] <JamesMSne> agreed. MessageExchange exchanges MessageContexts
[13:56] <GlenD> hold your horses. :)
[13:56] <GlenD> Though come to think of it, I can actually go finish this thinking on my own and write up an email about it.
[13:57] <GlenD> I'll do that and try to get it out this afternoon. It's just reaffirming some first concepts about this stuff.
[13:58] <JamesMSne> you will have an extremely difficult time convincing us (me, Jaime at the least) that using invoke is a good option
[13:58] <GlenD> It's not about using invoke per se.
[13:58] <GlenD> that's secondary.
[13:58] <GlenD> it's more about how the pieces fit together
[13:59] <JamesMSne> be sure to include a discussion of what pieces of ime you don't think fit together, because I'm just not seeing it
[13:59] <GlenD> check.
[13:59] <JamesMSne> a couple of points....
[13:59] <GlenD> Again, it's not that I think what's there is bad or anything. It's that I'm wondering if it could be simplified.
[14:00] <JamesMSne> 1. I initially looked at retrofitting async into the invoke mechanism and concluded that it would be a lot more work than its worth
[14:00] <JamesMSne> 2. Retrofitting async into the current invoke would not simplify anything since all of the same stuff needs to be implemented in either case
[14:01] <JamesMSne> 3. The MessageExchange approach is far more intuitive
[14:01] <GlenD> ok
[14:01] <GlenD> I'll take my questions to email. Any other IME stuff you guys want to cover on the chat?
[14:01] <kameshwar> James : To make myself clear MessageExchane is a MessageContext right?
[14:01] <JamesMSne> 4. The approach we're taking takes all of the complexity and stuffs it into utility classes
[14:01] <JamesMSne> kameshwar: no
[14:01] <GlenD> kameshwar: nope. [14:02] <JamesMSne> the MessageExchange is the interface through which MessageContexts are exchanged
[14:02] <JamesMSne> glen: just timeline
[14:02] <DaveChapp> Got another meeting to run to. Later.
[14:02] <GlenD> Take it easy Dave!
[14:02] *** DaveChapp has quit IRC (Quit: Trillian (http://www.ceruleanstudios.com))
[14:03] <JamesMSne> I'd like to get all of the transport senders migrated over to the async model by January with test cases
[14:03] <GlenD> i.e. end of January?
[14:03] <JamesMSne> I've already created the wrappers for the existing HttpSender, LocalSender and JavaSender
[14:03] <JamesMSne> beginning of January
[14:04] <JaimeMeri> I'll take care of the JMS sender [14:04] <JamesMSne> those wrappers take the current sender Handlers and wraps them into MessageExchangeProviders
[14:04] <JamesMSne> one of the biggest issues here is the WSDD code
[14:05] <JamesMSne> on WSDDTransport, createNewInstance() would need to return a MessageExchange rather than a handler
[14:05] <GlenD> um
[14:05] <JamesMSne> that would actually be the biggest change
[14:06] <GlenD> ok
[14:06] <JamesMSne> the point is to get AxisClient using the MessageExchange interface when calling the Transport senders rather than Handler.invoke()
[14:06] <JaimeMeri> We should also support the legacy syntax for transport definition if possible [14:07] <JamesMSne> for now, that communication would still be syncronous, using MessageExchange.sendAndReceive(), but it's a baby step
[14:08] <JaimeMeri> James: The sendAndReceive behavior will only change when the async client api is exposed. Is that correct? [14:08] <JamesMSne> jaime: kinda.
[14:09] <JamesMSne> when AxisEngine becomes a MessageExchangeProvider, we can make it async all the way through the engine and transports. the Call object would use sendAndReceive on the Axis engine
[14:09] <JamesMSne> then, when the client api is done, everything would be set up to make it all async
[14:10] <JamesMSne> the objective is to work from the bottom up
[14:10] <JamesMSne> transports first, then providers, then the engine that sits on top of the transports and providers, then the client api
[14:10] <JaimeMeri> Makes sense to me. Of course I drank the kool aid long ago :) [14:11] <JamesMSne> glen: I can understand if this all scares you given your concerns about the interfaces. we'll work through your concerns, but we're still going to move forward on the original plan
[14:11] <JamesMSne> the point is: we'll be doing a phased async conversion of all of the axis subsystems [14:11] <JamesMSne> one by one working our way up to the client api
[14:12] <kameshwar> great
[14:12] <JamesMSne> whatever that async mechanism ends up being in the end
[14:12] <JamesMSne> that way we're not trying to tackle too much at once
[14:12] <GlenD> check
[14:13] <JamesMSne> I gotta run, so getting back to specific task items
[14:13] *** DaveChapp has joined #ApacheAxis
[14:13] <JamesMSne> 1. I will remove FeatureEnabled for now
[14:13] <JamesMSne> 2. I will make MessageCorrelator an interface and create a SimpleMessageCorrelator
[14:13] <JaimeMeri> We're currently working on scoping out a potential client API that may be a good topic for discussion in the coming weeks [14:13] <JamesMSne> 3. I will add matches(MessageCorrelator) to the MessageCorrelator interface
[14:14] <JamesMSne> good topic of discussion == debate fodder :-)
[14:14] <JaimeMeri> :) [14:14] <JamesMSne> and, I'll start taking a look at the bug list
[14:14] <GlenD> sounds good
[14:14] <JaimeMeri> later James [14:14] <JamesMSne> later guys
[14:14] *** JamesMSne has quit IRC (Quit)
[14:16] <GlenD> OK, on to...
[14:16] <GlenD> schema stuff?
[14:16] <GlenD> Do we want to discuss this, or call the "official" chat there for today?
[14:17] <GlenD> It would be nice if Vidyanand could be here for that discussion, I suppose...
[14:17] <tjordahl> Yes, he should be around for that
[14:17] <kameshwar> Vidyanad i could callhim
[14:17] <kameshwar> and ask him to join the chat
[14:17] <GlenD> oh, you're in that stuff too, kameshwar!
[14:17] <kameshwar> i and vidyanad are colleagues
[14:17] <GlenD> I'm sorry, I totally spaced that.
[14:18] <GlenD> :)
[14:18] <kameshwar> in the same starup :)
[14:18] <GlenD> So have you guys taken a look at the way SymbolTable/SchemaUtils does its work yet?
[14:19] *** DaveChapp has quit IRC (Quit: Trillian (http://www.ceruleanstudios.com))
[14:19] <kameshwar> I think Vidyanand has not yet finished porting
[14:19] <GlenD> Is he actually working on it now?
[14:20] <kameshwar> i think but am not too sure as we have too much on our plate :-)
[14:20] <GlenD> I hadn't realize he'd gotten that far yet.
[14:21] <kameshwar> i am not too sure
[14:21] <kameshwar> Glen
[14:21] <kameshwar> i might be wrong :)
[14:21] <GlenD> ok
[14:22] <GlenD> So in any case, the first minor nit I have is the package structure.
[14:22] <GlenD> Seems like the enum and str packages could go away to move somewhere else, and the xml/schema package could collapse to just schema, moving the util functionality in xml elsewhere as well.
[14:23] <GlenD> so the bulk of the code would be org.apache.axis.schema.* or axis.xmlschema.*
[14:23] <kameshwar> glen
[14:23] <kameshwar> i am on line with Vidyanad
[14:23] <kameshwar> he is in Boston
[14:23] <kameshwar> and he is very eager to meet u personallu\y
[14:24] <GlenD> +1!
[14:24] <kameshwar> ifu can [14:24] <davanum> Kamesh: Ask him to call me too.
[14:24] <GlenD> How about Tom and Dims and Vidyanand and myself all go for lunch next week?
[14:24] <davanum> +1
[14:24] <kameshwar> he is for this week
[14:24] <davanum> Anyone else in Boston? Welcome to join us :)
-- end log - the rest was logistics for meeting up, which happened this afternoon --
