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