axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Please beta 1.1! (Was: Re: Today's IRC log)
Date Tue, 26 Nov 2002 23:26:42 GMT
Please reconsider the issue of doing a beta for 1.1, so that people can 
try it out and report new bugs. I've tried working with a recent daily 
build but ran into a couple of major problems just for simple 
RPC-encoded web service and client, and it sounds like others have had 
similar experiences with dailies - while most users won't try them at 
all. I'll retest my particular issues with the current daily and enter 
bug reports if something is still wrong, but the fact that this is 
happening at all says that the current CVS code is not in a really 
stable state.

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.
>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
>[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
>[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,
>[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
>[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
>[13:25] <GlenD> Second, why is MessageCorrelator not just an interface with a matches(MessageCorrelator)
>[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
>[13:33] <GlenD> gotcha
>[13:34] <JamesMSne> jaime: I agree that it's convenient, I just don't think it's
>[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
>[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
>[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
>[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
>[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
>[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
>[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
>[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 (
>[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
>[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
>[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 (
>[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 --

View raw message