axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Chappell <>
Subject Re: Today's IRC log
Date Wed, 27 Nov 2002 19:17:55 GMT
I dropped off before the end of the chat, but count me in if you are
doing lunch in the Boston area next week.

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
> [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 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
> [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
> [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
> [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 --

Sonic Software - Backbone of the Extended Enterprise
David Chappell <> 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)

View raw message