chat log 24/NOV/05

[Paul Fremantle <pz...@gmail.com>]

[12:54] *** Initial topic: Apache Synapse
http://incubator.apache.org/synapse/
[12:54] *** #apache-synapse: paulfremantle sanjiva anaZ
[12:54] *** #apache-synapse was created on Wed Oct 26 08:40:44 2005.
[12:55] paulfremantle: hi
[12:55] paulfremantle: anyone ACTUALLY here?
[13:00] *** saminda has joined #apache-synapse.
[13:01] saminda: hi
[13:01] paulfremantle: hi
[13:01] paulfremantle: noone here except us
[13:02] *** antelder has joined #apache-synapse.
[13:02] antelder: hi there
[13:02] paulfremantle: hiya
[13:03] saminda: Hi Ant
[13:04] saminda: There is another Prototype on the fly :), and i have
already voted for prototype1 ;0
[13:04] saminda: :)
[13:05] paulfremantle: yes did you see the commit and note ant?
[13:05] *** Chinthaka has joined #apache-synapse.
[13:05] paulfremantle: hi eran
[13:05] *** pvikas has joined #apache-synapse.
[13:05] antelder: yes, not looked yet, jut checking it out now...
[13:05] paulfremantle: hi vikas
[13:06] *** Sathish has joined #apache-synapse.
[13:06] pvikas: hi everyone
[13:06] antelder: hi
[13:06] *** sanjiva has signed off IRC (Read error: 113 (No route to host)).
[13:06] Chinthaka: hi Paul and all
[13:06] Chinthaka: have u started ?
[13:07] Chinthaka: where is the Turkey man ? :)
[13:07] *** Harry has joined #apache-synapse.
[13:07] *** Sankar has joined #apache-synapse.
[13:07] saminda: He is having Turkey :)
[13:07] Harry: hi have u guys started
[13:08] paulfremantle: no really
[13:08] paulfremantle: hi Harry
[13:08] Harry: hi paul
[13:08] paulfremantle: so I don't know if you guys spotted it
[13:09] paulfremantle: but I have messed up the nice plan to move to HEAD
[13:09] paulfremantle: with a new prototype
[13:09] paulfremantle: there is a note and a commit
[13:09] Chinthaka: what was the problem ?
[13:10] paulfremantle: so some comments from mukund, glen and ant
[13:10] paulfremantle: made me realise we could simplify the code a lot
[13:10] paulfremantle: and make it more powerful
[13:10] paulfremantle: and since it was a fairly big refactor I thought it
better to do BEFORE we move to head
[13:11] paulfremantle: so the new code is simpler and better :-)
[13:12] paulfremantle: and retains pretty much the same synapse.xml
[13:12] pvikas: can we get a fast dump on it... i don't think many had a
chance to go through it..
[13:12] paulfremantle: sure
[13:12] paulfremantle: so what it seemed looking at it was
[13:12] paulfremantle: SynapseEngine, RuleEngine, Rule were all doing the
same thing
[13:13] paulfremantle: and we could have instead a single Processor class
[13:13] pvikas: does that still leave us with pluggable engines?
[13:13] paulfremantle: yes
[13:13] paulfremantle: in fact its easier to plug :-)
[13:13] paulfremantle: so.... when it parses the synapse.xml
[13:14] paulfremantle: it looks at the QName of the element
[13:14] pvikas: so we get
SynapseEngine+RuleEngine1+RuleEngine2....+RuleEngine(N) = Synapse Processor
[13:14] paulfremantle: it does ProcesserFinder.find(qname)
[13:14] paulfremantle: which gives it the class of Processor
[13:15] paulfremantle: it then calls processor.compile(OMElement) which
gives it a useful object
[13:15] paulfremantle: there are roughly two kinds of Processors
[13:15] paulfremantle: the nodes (stages + rules)
[13:15] paulfremantle: and the leaves (mediator types)
[13:16] pvikas: [maybe i am too slow at grasping this] the processor merges
the capabilities of the classes we called Synapse engine and rule engine?
[13:16] paulfremantle: yes vikas!
[13:16] paulfremantle: exactly
[13:16] paulfremantle: and it also takes on some code that was hard coded to
call mediators too
[13:16] pvikas: so when u say ProcessorFinder.find(qname)
[13:17] pvikas: we get a set of Synapse Engine+RuleEngine (figuratively
speaking)
[13:17] paulfremantle: ues
[13:17] paulfremantle: yes
[13:17] pvikas: so correlating to our previous terminology
[13:18] pvikas: every ruleset would lead to a SynapseEngine+RuleEngine
configuration
[13:18] paulfremantle: yes
[13:18] paulfremantle: Basically there is a class Configurator
[13:18] paulfremantle: with a method
[13:18] paulfremantle: Processor getProcessor(env, OMElement)
[13:19] paulfremantle: and the "node" types (rules, stages) call this
recursively to process subchildren
[13:19] paulfremantle: so the BIG benefit
[13:19] paulfremantle: is that you can have rules within rules
[13:19] paulfremantle: so I can do this:
[13:19] paulfremantle:  <regex message-address="to" pattern="
http://xmethods.*">
           <header type="to" value="http://64.124.140.30:9090/soap"/>
           <xpath expr="//*[Symbol='MSFT']">
                <fault/>
           </xpath>
      </regex>
[13:19] pvikas: so u resolve the dependent or priori rules by going this way
[13:19] paulfremantle: so the first test looks for stockquote services
[13:20] paulfremantle: if that is true
[13:20] paulfremantle: then I fix up headers
[13:20] paulfremantle: then I can do *another* test
[13:20] paulfremantle: (is this Microsoft? then fault back)
[13:20] paulfremantle: so the xpath only gets executed on the stockquote
requests
[13:20] paulfremantle: which is much more efficient
[13:20] pvikas: agreed
[13:20] saminda: agreed
[13:21] paulfremantle: that was actually youre (Infravios) idea :-)
[13:21] pvikas: but why pack synapse engines for different ruleSet...(i like
the older terms, convenient)
[13:21] paulfremantle: pack?
[13:22] saminda: ?
[13:22] pvikas: i mean findProcessor would return a processor that
encapsulates the engine's functionalities
[13:22] paulfremantle: yes
[13:22] pvikas: both synapse engine and rule engine..
[13:22] paulfremantle: because they both had the API
[13:22] paulfremantle: boolean process(SMC)
[13:22] paulfremantle: roughly
[13:23] saminda: {just for clearity } seems to be there are built in
mediators
[13:23] pvikas: so instead of having a single synapse engine and various
rule engines for different rulesets, like we had earlier
[13:24] pvikas: we would now have a different config of synapse engine and
rule engine for every mediator
[13:24] pvikas: is that it?
[13:24] paulfremantle: i dont think so vikas but i dont understand the
question
[13:25] pvikas: processor  = Synapse engine+rule engine (yes/no)
[13:25] saminda: "We have" SynapseProcessor
[13:25] saminda: which will resembles this behavior, right
[13:25] paulfremantle: so you have a structure of processor -> [child
processors -> [child processors -> [mediators]]]
[13:26] paulfremantle: where the first processor is the synapse engine and
the first child processors are stages
[13:26] pvikas: i still am not at terms with what the processors are..
please clarify
[13:26] paulfremantle: then the next processors are rules
[13:26] paulfremantle: here is a real synapse.xml for the new ptype
[13:26] paulfremantle: <synapse xmlns="http://ws.apache.org/ns/synapse">

     <stage name="logall">
         <addressing/>
           <log/>
     </stage>
     <stage name="service-specific" >
           <regex message-address="to" pattern="http://xmethods.*">
                <header type="to" value="http://64.124.140.30:9090/soap"/>
                <xpath expr="//*[Symbol='MSFT']">
                     <fault/>
                </xpath>
           </regex>
      </stage>
      <stage name="sender">
           <send/>
      </stage>

 </synapse>


[13:27] Harry: paul can you please tell you the functionality of the
processor
[13:27] paulfremantle: public interface Processor {
      public void compile(SynapseEnvironment se, OMElement el);

      public boolean process(SynapseEnvironment se, SOAPMessageContext smc);



 }

[13:27] Harry: paul  can you please tell us the functionality of the
processor
[13:27] paulfremantle: I'm trying  Harry!
[13:28] Harry: :-)
[13:28] paulfremantle: the SynapseEngine is now SynapseProcessor
[13:28] paulfremantle: It just runs all its children on every message
[13:28] paulfremantle: it has StageProcessor's as children
[13:28] paulfremantle: Each StageProcessor runs its children
[13:29] pvikas: so we use the word processors instead of engines now?
[13:29] paulfremantle: yes
[13:29] paulfremantle: so if we look at the example xml above the first
stage has two children
[13:29] pvikas: ruleProcessors and synapseProcessors are different
[13:29] paulfremantle: both are processors
[13:30] pvikas: i mean the findProcessor returns the relevant processor
depending on the position in the hierarchy and the qname...
[13:30] paulfremantle: yes exactly
[13:30] paulfremantle: no
[13:30] paulfremantle: just the QName
[13:30] paulfremantle: not the position in the hierarchy
[13:31] paulfremantle: so this means that you can nest elements
[13:31] paulfremantle: which is how we do the rule -> rule nesting I
described above
[13:31] pvikas: so this is like returning the relevant rule engine alone
[13:31] pvikas: we have one synapse processor and various ruleProcessors..
[13:32] paulfremantle: yes
[13:32] pvikas: thanks
[13:32] paulfremantle: and SpringMediatorType will fit in as a processor
[13:33] paulfremantle: as will ScriptMediatorType
[13:33] pvikas: thats what i was confused about b'cause i was under the
impression that the same processor holds config for synapse engine and rule
engine
[13:33] pvikas: thanks for clarifying paul
[13:33] *** mukund_ has joined #apache-synapse.
[13:35] paulfremantle: in fact it is very similar to the previous code....
but just makes a general class out of some specific instances
[13:35] paulfremantle: but i think the result is more flexible
[13:35] paulfremantle: and useful
[13:36] pvikas: and the type attribute has been removed because the qname
takes care of resolving  the procesor issue?
[13:36] paulfremantle: yes.... Glen gave me a lot of XML grief over the type
attribute
[13:36] paulfremantle: saying it was badly wrong in XML terms
[13:36] paulfremantle: (no schema validation)
[13:40] pvikas: what about the stage ordering?
[13:40] pvikas: or rule set ordering
[13:40] paulfremantle: so at the moment it is all in the order specified in
the XMl
[13:40] saminda: according to the code when we introducing a new type of
mediator
[13:41] paulfremantle: but that is up to the processor
[13:41] pvikas: u mean the SynapseProcessor
[13:41] paulfremantle: so if you want to make a stage that uses a different
ordering
[13:41] saminda: we have to introduce another MR, it this the behavior
[13:41] paulfremantle: you can
[13:41] pvikas: MR?
[13:41] paulfremantle: it is up to EACH processor how it processes its
children
[13:41] pvikas: message receiver
[13:41] Sathish: Msg Receiver ?
[13:41] paulfremantle: hold on saminda
[13:42] paulfremantle: it is up to EACH processor how it processes its
children
[13:42] paulfremantle: so if I want to have an xpathStage
[13:42] paulfremantle: that does its own ordering
[13:42] paulfremantle: I can do that
[13:43] paulfremantle: I havent yet done <in> and <out>
[13:43] paulfremantle: but that will be easy in this model
[13:44] pvikas: the mediator configurator, it holds mediator specific
parameters which apply to all services right?
[13:44] paulfremantle: the mediator configuration
[13:44] pvikas: oh yeah
[13:45] paulfremantle: is simply a way of parsing stuff ahead of time
[13:45] saminda: filtering the "processors" in SynapseProcessor ?
[13:45] paulfremantle: so i dont want to parse the configuration EVERY time
I handle a message
[13:45] paulfremantle: so I do it ahead of time
[13:45] paulfremantle: it may be that can also be refactored a little
[13:45] pvikas: any thoughts on 'service specific'/'mediator' dependent
parameters?
[13:45] paulfremantle: I haven't looked on it yet
[13:46] paulfremantle: well you can do that simply today
[13:46] paulfremantle: by doing <regex pattern="service1>
[13:46] pvikas: i was working on it but there is this problem..
[13:47] paulfremantle: <mediator><service1 config></mediator>
[13:47] paulfremantle: </regex>
[13:47] saminda: Paul, when <mediator/>  is present, there should be a
MediatorConfiguration
[13:47] pvikas: imagine a failover scenario
[13:47] pvikas: we would need one such expression for every other service
that is mediated
[13:48] pvikas: too bulky to define in synapse.xml
[13:48] paulfremantle: yes.... so we need some extra stuff
[13:48] paulfremantle: 1) we need references to mediators
[13:48] paulfremantle: so <reference name="medname">
[13:48] pvikas: paul, can u be a bit more precise?
[13:49] paulfremantle: uses the mediator called "medname" that is defined
elsewhere
[13:49] paulfremantle: i'll try
[13:49] paulfremantle: :-)
[13:49] *** Karni has joined #apache-synapse.
[13:49] *** Karni is n=chatzill@220.225.137.194 (New Now Know How)
[13:49] *** Karni is on: #apache-synapse
[13:49] *** Karni is using irc.freenode.net http://freenode.net/
[13:49] *** Karni has been idle 10 seconds, signed on at Thu Nov 24 13:48:47
2005
[13:49] *** End of /WHOIS.
[13:49] paulfremantle: suppose I have a single load-balancing mediator
[13:49] pvikas: i was thinking of something along the following lines...
[13:49] paulfremantle: <mediator name="loadbalancer">
[13:49] paulfremantle: I can call it from elsewhere
[13:49] paulfremantle: using
[13:50] paulfremantle: <reference name="loadbalancer">
[13:50] pvikas: [Paul] i think i am lost..
[13:50] paulfremantle: [vikas] what is your idea
[13:50] Harry: i think paul  is taking about a spring implementation
[13:51] paulfremantle: actually Harry I wasnt!
[13:51] pvikas: ok..imagine a failover scenario
[13:51] pvikas: There are 'n' services which provide the same functionality
[13:52] pvikas: so we have a mediator which handles this..its called
failoverMediator
[13:52] paulfremantle: ok
[13:52] pvikas: its supposed to be generic..so no hardcoding a specific set
into it
[13:53] paulfremantle: of course
[13:53] pvikas: it needs to get the list of services it can use if one fails
[13:53] paulfremantle: yes
[13:53] pvikas: this is based on the service to which the request is
addressed
[13:54] paulfremantle: yes
[13:54] pvikas: if we put these parameters at some place in synapse.xml ...
[13:54] pvikas: it would be like..
[13:55] pvikas: if WSATo:Service1...
[13:55] pvikas: list of failover services
[13:55] pvikas: now the same would need to be done for service2.. to service
'n'
[13:55] paulfremantle: but you could just as easily write a mediator
[13:55] paulfremantle: that gets the list from a database
[13:56] paulfremantle: or another service
[13:56] pvikas: even if  its external we would need to provide these
parameters for every service in the group
[13:57] pvikas: we have only one dummy SynapseService to which all requests
are sent..right?
[13:57] paulfremantle: so you could have
[13:57] pvikas: imagine having a dummyService for every group u r mediating
[13:57] paulfremantle: <mediation name="fail" class="failovermediator">
[13:58] paulfremantle:  <property
name="servicelistdatabase">jdbc:mydb:servicelistdatabase</property>
[13:58] paulfremantle: </mediation>
[13:59] pvikas: but then synapse would have no logical notion of acting as a
screen for all the services in the set...
[14:00] paulfremantle: i dont understand why you say that?
[14:00] paulfremantle: the synapseservice is kind of irrelevent
[14:00] paulfremantle: it is just the way we are getting requests into
synapse from axis2
[14:00] paulfremantle: it is not part of the core engine
[14:01] pvikas: agreed, but what i  say is that we go a step further and
actually differentiate between different services that are being mediated
[14:02] paulfremantle: i understand... but i dont understand HOW you propose
doing that
[14:02] pvikas: things addressed to DummyService1 in synapse are for
services s1....Sn
[14:02] paulfremantle: but vikas
[14:02] pvikas: that will be configuration time work
[14:02] paulfremantle: the PROBLEM with tha
[14:02] paulfremantle: that
[14:02] paulfremantle: is that it just pushes it back a step
[14:03] paulfremantle: and also it means that I dont have a bus model
[14:04] pvikas: i think we have to go ant's way.. i ll drop a use case of
the scenario and the proposal in the mailing list
[14:04] paulfremantle: there is nothing to stop you deploying
SynapseMessageReceiver against different services in Axis2 config
[14:05] paulfremantle: Ant's way?
[14:05] pvikas: [he and glen keep asking for usecases :-) ]
[14:05] antelder: use cases and scenarios. i think it was glens way
[14:05] paulfremantle: aha yes
[14:05] paulfremantle: +1
[14:06] paulfremantle: so it would be very easy to write a switchprocessor
[14:06] paulfremantle: <switchprocessor>
[14:06] paulfremantle: <case to="service1><do service1 stuff></case>
[14:07] paulfremantle: actually
[14:07] paulfremantle: <switchprocessor on="to-address">
[14:07] paulfremantle:  <case value="service1">
[14:07] paulfremantle: <case value="service2">
[14:07] paulfremantle: etc
[14:08] paulfremantle: which will differentiate between different services
[14:09] pvikas: if dummyservice1 = service1,service2,service3
[14:09] pvikas: dummyservice2 = service 4,service5,service6,service7
[14:09] pvikas: then this becomes even more easier...
[14:10] paulfremantle: please send the use case to the mailing list and the
proposal
[14:10] paulfremantle: what do you guys think of proto3?
[14:10] paulfremantle: (i think the failover model is the same issue for
proto2 and proto3)
[14:11] antelder: Sorry, i've been a bit preoccupied and missed most of
this, I'm only just looking at it now so will have to think about it for a
bit. skimming over i've a couple of things
[14:11] antelder: package org.apache.synapse has a lot of xml config stuff,
could that be moved to some other package so its not the 1st thing you see?
[14:11] pvikas: have to go through the code..otherwise the idea of having
priori rules sounds cool
[14:12] paulfremantle: ok ant.... i tried to make the package structure
useful
[14:12] paulfremantle: which means there isnt much in synapse itself
[14:12] antelder: the terms mediator and processor is a bit confusing. Maybe
"processor" isnt the right word but I don't have an alternative to offer
right now
[14:12] paulfremantle: ok
[14:12] antelder: package org.apache.synapse.processors.mediators, all
classes are named XxxProcessor, and none implement Mediator???
[14:12] paulfremantle: so none of those are mediators :-)
[14:13] paulfremantle: they are processors
[14:13] paulfremantle: that are "leaves" not "nodes"
[14:13] antelder: just saying some of this is a little confusing
[14:13] paulfremantle: yep
[14:13] antelder: Also having "built in" mediators and processors makes it
feel like the pluggable mechanisim might be too hard to use, if its good
enough for others to use why doesn't Synapse itself?
[14:14] paulfremantle: the difference between writing a mediator and a
processor
[14:14] paulfremantle: is that you don't have to handle any config xml to
write a processor
[14:14] paulfremantle: WRONG
[14:14] paulfremantle: is that you don't have to handle any config xml to
write a MEDIATOR
[14:15] pvikas: so these processors actually take care of preparing the
scene for the mediators?
[14:15] paulfremantle: and to write a processor requires understanding
config XML and also packaging as a JAR file etc
[14:15] paulfremantle: yes
[14:15] paulfremantle: exactly
[14:15] paulfremantle: so the classMediatorProcessor
[14:16] antelder: so should ConfigurationAware  be in the API package then?
[14:16] paulfremantle: lets me write mediator classes that are loaded as
classes and run
[14:16] pvikas: so the mediatorConfiguration just returns the relevant
OMElement
[14:16] paulfremantle: no....
[14:17] pvikas: then?
[14:17] paulfremantle: the MediatorConfigurator takes the OMElement and
turns it into something simple the mediator can understand
[14:17] paulfremantle: which is a MediatorConfiguration
[14:17] pvikas: then where exactly do the MediatorProcessors come in?
[14:18] antelder: but couldn't that be a Mediator specific things and use DI
to give it to the Mediator, not a MediatorConfiguration object?
[14:18] paulfremantle: ok
[14:18] *** Chinthaka has signed off IRC ("Chatzilla 0.9.68.5 [Firefox 1.0.7
/20050915]").
[14:18] paulfremantle: let me try and explain vikas
[14:18] pvikas: yup
[14:18] paulfremantle: yes Ant .... which is why ConfigurationAware is
optional
[14:19] paulfremantle: the ClassMediatorProcessor
[14:19] paulfremantle: calls the ClassMediator
[14:19] paulfremantle: instance
[14:19] antelder: maybe like an SPI thing?
[14:19] pvikas: so they represent the mediator calling part...
[14:20] paulfremantle: sorry guys i'm getting lost with two conversations at
once
[14:20] paulfremantle: my brain is going fizzle put bang
[14:21] pvikas: [make a pick]
[14:21] paulfremantle: i think i need to take another look at the
mediatorConfigurator/MediatorConfiguration
[14:21] paulfremantle: I haven't changed or touched it from proto2
[14:21] pvikas: hmmm...
[14:21] paulfremantle: maybe - as I said earlier - it needs some refactoring
too
[14:22] paulfremantle: not sure yet
[14:22] antelder: so you know I'm not a fan of EnvironmentAware /
ConfigurationAware.
[14:22] antelder: so many places use both SynapseEnvironment and
SOAPMessageContext, eg, process(SynapseEnvironment se, SOAPMessageContext
smc)
[14:22] antelder: I know I've asked before...in the api package could we get
rid of EnvironmentAware and have getSynapseEnvironment on the
SOAPMessageContext, and move SynapseEnvironment to SPI package
[14:22] paulfremantle: yeah I know :-)
[14:22] antelder: need to think more about ConfigurationAware and
MediatorConfiguration, could they be in SPI, get rid of ConfigurationAware,
maybe use DI for mediators that need simple stuff or
smc.getSynapseEnvironment().getMediatorConfiguration() if they need the
details?
[14:22] paulfremantle: can you send a note to the mailing list?
[14:23] paulfremantle: and we can vote on it
[14:23] paulfremantle: I don't like that because I think we are polluting an
object that is ONLY the message and message-specific stuff
[14:23] paulfremantle: with things that are not message-specific
[14:24] antelder: maybe it should be SynapseMessage instead of
SOAPMessageContext?
[14:24] paulfremantle: I'm happy with that now it is no longer part of Axis2
[14:25] paulfremantle: but I still dont think the environment should be part
of it
[14:25] antelder: in an example there was a stage with "<addressing/>", what
does that do, is this replacing the engaging axis2 modules / qos stuff from
before?
[14:25] paulfremantle: it does exactly that.... it engages the axis2
addressing module
[14:25] paulfremantle: because if it is "on by default" it gets run too many
times
[14:28] antelder: theres a specific AddressingProcessor, so to engage other
axis2 modules we'd have to write a processor for each?
[14:28] paulfremantle: no we could generalise it
[14:28] paulfremantle: depends on what makes the easiest syntax
[14:28] pvikas: there is something of that sort in the scratch/infravio part
[14:29] pvikas: but these bring us to the question of preserving the
axisConfiguration?
[14:30] paulfremantle: ?
[14:30] paulfremantle: go on
[14:31] pvikas: well i engage a certain module to a service in an
axisConfiguration and need that service without that qos in another case..
[14:31] pvikas: i need a new config, dont i?
[14:31] paulfremantle: no
[14:31] paulfremantle: we disable all modules by default
[14:31] paulfremantle: and then use synapse.xml
[14:31] paulfremantle: to enable for specific services
[14:32] pvikas: services imply Native enf points
[14:32] pvikas: oops end points
[14:32] pvikas: or mediators?
[14:32] paulfremantle: so the example
[14:32] paulfremantle: shows
[14:33] paulfremantle: turning on addressing
[14:33] paulfremantle: and this can be as a result of a rule
[14:33] paulfremantle: or generically
[14:33] paulfremantle: the same is true for other modules
[14:34] pvikas: all axis based mediators reside in the same axisConfig?
[14:34] paulfremantle: if i understand the q - yes
[14:35] pvikas: and if i need a qos module q1 for this mediator i engage it
to it in this config
[14:35] pvikas: right?
[14:35] paulfremantle: or there can be a mediator
[14:36] paulfremantle: like the <addressing/> that is in proto3
[14:36] paulfremantle: that engages it
[14:36] pvikas: great..
[14:36] paulfremantle: but i think this is all post M1
[14:36] pvikas: but then a qos, mediator set is specific to a condition...
[14:36] pvikas: if i need the same mediator without any qos??
[14:36] pvikas: what do i do?
[14:37] paulfremantle: so
[14:37] paulfremantle: if I want addressing
[14:37] paulfremantle: i do
[14:37] paulfremantle: <addressing/>
[14:37] paulfremantle: <log/>
[14:37] paulfremantle: if I don't want addressing
[14:37] paulfremantle: I do
[14:37] paulfremantle: <log/>
[14:38] paulfremantle: so its getting very late in SL!!!
[14:38] pvikas: but since the module is already engaged in the axisConfig..
would just <log/> actually have an effect?
[14:38] paulfremantle: no.... the module is NOT engaged by default
[14:38] paulfremantle: can I summarise the actions out of this chat
[14:38] paulfremantle: 1) everyone to look at proto3
[14:39] paulfremantle: 2) I will restructure the packages to make more sense
[14:39] paulfremantle: 3) I will rename SMC to SynapseMessage
[14:39] paulfremantle: 4) Ant will post a note about SM.getEnvironment which
I will argue against :-)
[14:39] paulfremantle: 5) I will take a new look at mediatorconfig stuff
[14:40] pvikas: can you please mail a process flow too...
[14:40] paulfremantle: and propose a change or write an explanation too
[14:40] paulfremantle: a process flow?
[14:40] pvikas: a bit of a detail on what happens where...
[14:41] pvikas: in he prototype
[14:41] paulfremantle: I can do a sequence diagram
[14:41] pvikas: [missed the t]
[14:41] pvikas: ok
[14:42] saminda: I think the code is more clear to figure out the flow
[14:42] paulfremantle: 6) sequence diagram
[14:42] pvikas: [saminda] a doc is always handy ;-)