I dropped off before the end of the chat, but count me in if you are doing lunch in the Boston area next week. Dave
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 -- -- Sonic Software - Backbone of the Extended Enterprise -- David Chappell <[EMAIL PROTECTED]> Office: (781)999-7099 Mobile: (617)510-6566 Vice President and Chief Technology Evangelist, Sonic Software co-author,"Java Web Services", (O'Reilly 2002) "The Java Message Service", (O'Reilly 2000) "Professional ebXML Foundations", (Wrox 2001) --
begin:vcard n:Chappell;Dave tel;cell:617-510-6566 tel;work:781-999-7099 x-mozilla-html:FALSE url:www.sonicsoftware.com org:Sonic Software Corp. <BR><BR><A HREF="http://www.sonicsoftware.com/products/sonicxq.htm";>Read about SonicXQ</A> - the first product to deliver <br>on the promise of the enterprise service bus.<BR><BR><A HREF="http://www.sonicsoftware.com";><IMG BORDER="0" SRC="http://www.sonicsoftware.com/media/email_signatures/schulte_quote_logo2.gif";></A> adr:;;14 Oak Park;Bedford;MA;01730;USA version:2.1 email;internet:[EMAIL PROTECTED] title:vice president & chief technology evangelist<a href="http://www.oreillynet.com/weblogs/author/207";>[weblog]</a> fn:Dave Chappell end:vcard
![http://www.sonicsoftware.com/media/email_signatures/schulte_quote_logo2.gif"](http://www.sonicsoftware.com/media/email_signatures/schulte_quote_logo2.gif"){kind=link}