[00:04:37] *** babo has quit IRC
[00:09:31] *** tcunning has quit IRC
[00:14:48] *** lanceball has quit IRC
[00:29:43] *** aslak has quit IRC
[00:48:23] *** aamonten has quit IRC
[00:56:55] *** tcunning has joined #switchyard
[00:57:01] *** errantepiphany has left #switchyard
[01:32:23] *** tcunning has quit IRC
[01:33:35] *** bfitzpat has quit IRC
[01:33:55] *** tcunning has joined #switchyard
[01:42:06] *** tcunning has quit IRC
[01:54:59] *** kcbabo has joined #switchyard
[02:25:01] *** rcernich has quit IRC
[02:34:13] *** tcunning has joined #switchyard
[02:40:45] *** ldimaggi has joined #switchyard
[03:11:35] *** GitHub151 has joined #switchyard
[03:11:35] <GitHub151> [core] kcbabo pushed 1 new commit to master: http://bit.ly/qZd5nz
[03:11:35] <GitHub151> [core/master] [SWITCHYARD-330] - Fixed Smooks dependencies - Magesh Kumar B
[03:11:35] *** GitHub151 has left #switchyard
[03:15:18] *** tcunning has quit IRC
[03:30:50] *** tcunning has joined #switchyard
[04:17:44] *** aamonten has joined #switchyard
[04:49:35] *** aamonten has quit IRC
[04:53:03] *** ldimaggi has quit IRC
[04:59:00] *** aamonten has joined #switchyard
[05:10:59] *** aamonten has quit IRC
[05:24:27] *** kcbabo has quit IRC
[06:13:50] *** magesh has joined #switchyard
[06:26:15] *** tcunning has quit IRC
[07:46:23] *** aslak has joined #switchyard
[07:46:23] *** aslak has quit IRC
[07:46:23] *** aslak has joined #switchyard
[09:39:23] *** aslak has quit IRC
[09:39:58] *** aslak has joined #switchyard
[12:42:31] *** kcbabo has joined #switchyard
[12:55:15] <kcbabo> magesh:  hey magesh
[12:55:33] <kcbabo> magesh:  thanks for sorting out that build issue - stupid mistake on my part
[12:55:38] <magesh> kcbabo: Hi Keith, Good Morning!
[12:55:53] <magesh> kcbabo: nps, as always my pleasure :)
[12:56:15] <kcbabo> magesh:  as a bonus, I think your change should mean that the quickstarts are included in the nightly builds
[12:56:22] <kcbabo> magesh:  which some folks were asking about
[12:56:27] <magesh> kcbabo: yes :)
[12:56:53] <kcbabo> magesh:  hey, when you have a chance, could you take a quick peak at this:
[12:56:54] <kcbabo> https://github.com/kcbabo/components/commit/d34ea13ad5984ad24f774727fcdd26a0cfbeb419
[12:57:12] <kcbabo> magesh:  I'm not ready for a pull request yet (need another change to transformer stuff), but these are the only changes to SOAP component
[12:57:54] <kcbabo> magesh:  background on the change can be found here https://issues.jboss.org/browse/SWITCHYARD-331
[12:59:11] <kcbabo> magesh:  shouldn't  have any significant impact because you can still get an Element out of the message content by simply saying message.getContent(Element.class)
[12:59:26] <kcbabo> magesh:  I added a transformer from DOMSource -> Element to support that
[13:00:06] <magesh> kcbabo: Seems okay to me
[13:00:21] <kcbabo> magesh:  okie doke - thanks for the look
[13:00:47] <kcbabo> magesh:  I was hoping to have the pull request ready, but there's an issue with transformer type discovery that needs to be fixed as part of this
[13:00:58] <kcbabo> magesh:  and didn't have the energy to tackle that last night
[13:01:17] <magesh> kcbabo: No worries, I am just having nightmares with the threading issue SWITCHYARD-309
[13:01:33] <kcbabo> magesh:  threading will do that to you :-)
[13:01:39] <magesh> kcbabo: lol
[14:15:01] *** kcbabo is now known as babo_brb
[14:26:19] *** tcunning has joined #switchyard
[14:36:00] *** aamonten has joined #switchyard
[14:43:17] *** wyer has joined #switchyard
[14:45:06] *** magesh has left #switchyard
[14:53:02] *** ldimaggi has joined #switchyard
[15:31:23] *** jgraham_ has joined #switchyard
[15:33:47] *** bfitzpat has joined #switchyard
[15:44:02] *** babo_brb is now known as kcbabo
[15:47:15] *** wyer has left #switchyard
[16:00:28] *** antollinim has joined #switchyard
[16:08:35] *** lanceball has joined #switchyard
[16:13:14] *** errantepiphany has joined #switchyard
[16:27:06] *** GitHub116 has joined #switchyard
[16:27:06] <GitHub116> [core] kcbabo pushed 1 new commit to master: http://bit.ly/oQ7nqW
[16:27:06] <GitHub116> [core/master] SWITCHYARD-318: ClientProxyBean.createExchange does not set exchange contract - Tom Fennelly
[16:27:06] *** GitHub116 has left #switchyard
[16:31:47] *** ldimaggi has quit IRC
[16:37:20] *** ldimaggi has joined #switchyard
[16:37:34] *** rcernich has joined #switchyard
[16:40:01] *** GitHub115 has joined #switchyard
[16:40:01] <GitHub115> [components] kcbabo pushed 1 new commit to master: http://bit.ly/qUe7ea
[16:40:01] <GitHub115> [components/master] SWITCHYARD-318: ClientProxyBean.createExchange does not set exchange contract - Tom Fennelly
[16:40:01] *** GitHub115 has left #switchyard
[16:58:00] *** ldimaggi has quit IRC
[17:10:44] *** ldimaggi has joined #switchyard
[17:46:18] *** rcernich is now known as rcernich_away
[17:50:18] *** GitHub69 has joined #switchyard
[17:50:18] <GitHub69> [components] kcbabo pushed 1 new commit to master: http://bit.ly/oyftWz
[17:50:18] <GitHub69> [components/master] SWITCHYARD-322 Support service name on @Service annotation - Mario Antollini
[17:50:18] *** GitHub69 has left #switchyard
[17:53:20] *** GitHub184 has joined #switchyard
[17:53:20] <GitHub184> [quickstarts] kcbabo pushed 1 new commit to master: http://bit.ly/nm69ku
[17:53:20] <GitHub184> [quickstarts/master] SWITCHYARD-281: switchyard.xml in transform-json quickstart is invalid - Alejandro Montenegro
[17:53:20] *** GitHub184 has left #switchyard
[18:24:43] *** kcbabo is now known as babo_afk
[19:16:56] *** babo_afk is now known as kcbabo
[19:40:31] <errantepiphany> kcbabo: ping
[20:18:33] *** rcernich_away is now known as rcernich
[20:24:41] <kcbabo> errantepiphany:  hey, what's up?
[20:27:01] <errantepiphany> kcbabo: Working on https://issues.jboss.org/browse/SWITCHYARD-296 . Turns out there is no bug UNLESS you have a slash in the promote name.  Easy enough to handle, IF you understand what the slash MEANS. Which brings up my main question, since I think we've been doing it wrong...
[20:27:51] <errantepiphany> kcbabo: check out page 17 of http://www.davidchappell.com/articles/introducing_sca.pdf
[20:28:48] <kcbabo> errantepiphany:  ok, I looked at it
[20:29:40] <errantepiphany> kcbabo: <service name=?A? promote=?Component1/A> does NOT mean promote service "A" within "Component1". It seems to me it means promote myself (COMPOSITE service "A") as the service of "Component1".
[20:29:51] <errantepiphany> kcbabo: I don't really understand the point...
[20:30:18] <errantepiphany> kcbabo: Other examples are: http://download.oracle.com/docs/cd/E15261_01/salt/docs11gr1/prog/sca.html and http://goo.gl/6FbMf
[20:30:50] <kcbabo> errantepiphany:  AFAIK, the promote attribute identifies the component and service/reference that should be promoted
[20:30:51] <errantepiphany> kcbabo: the 2nd string token (the substring after the slash) seems to always be the name of THAT service itself. So, what the f is the point?
[20:30:59] <kcbabo> errantepiphany:  I'm 99% sure of this
[20:31:06] <kcbabo> errantepiphany:  but to make sure I'll check the actual spec
[20:31:39] <errantepiphany> kcbabo: yeah, but if the name of the service/reference is the component service/reference itself, what are you actually promoting?
[20:32:09] <kcbabo> errantepiphany:  a promotion is saying that a given component is visible outside a composite
[20:32:27] <kcbabo> errantepiphany:  either through an explicit binding
[20:33:16] <kcbabo> errantepiphany:  or the implicit 'local' binding, meaning it's registered on the bus
[20:33:35] <kcbabo> errantepiphany:  it's a method of encapsulation for services and references
[20:34:55] <errantepiphany> kcbabo: Take the pg 17 pdf example...
[20:34:57] <kcbabo> errantepiphany:  from the 1.1 CD07 spec :
[20:34:57] <kcbabo> "identifies the promoted service, the value is of the form <component- 1385	name>/<service-name>. The service name can be omitted if the target component only has one 1386	service. "
[20:35:17] <errantepiphany> kcbabo: <service name=?A? promote=?Component1/A?>  Why do you need the "/A"?
[20:36:17] <kcbabo> errantepiphany:  it's worth noting that article most likely references the 1.0 version of the spec before it was moved to OASIS
[20:36:25] <errantepiphany> kcbabo: okay
[20:36:28] *** jgraham_ has quit IRC
[20:36:29] <kcbabo> errantepiphany:  so things have definitely changed between now and then
[20:36:30] <errantepiphany> kcbabo: phew
[20:37:05] <kcbabo> errantepiphany:  and to be honest, some examples I have seen with SCA can be a bit deceiving
[20:37:36] <errantepiphany> kcbabo: That would explain a lot. So in the case of CompositeServices and CompositeReferences, a promote attribute is either "componentName" or "componentName/serviceName" (or "componentName/referenceName")
[20:37:44] <kcbabo> errantepiphany:  for example, implementation.java components can be a mish mash of SCDL and Java annotations in the Java class themselves
[20:38:17] <kcbabo> errantepiphany:  so in the example in chappel's paper, the Java service class could be annotated with an @Service which defines service A
[20:38:27] <kcbabo> errantepiphany:  and he's not showing that in the SCDL snip
[20:38:38] <errantepiphany> kcbabo: okay, there's the deceiving part
[20:38:42] <kcbabo> errantepiphany:  totally
[20:38:55] <errantepiphany> kcbabo: it was twisting my brain. grrradfasdfji;jlk;!!!
[20:38:59] <kcbabo> errantepiphany:  looks great with block diagrams though ;-)
[20:39:13] <kcbabo> errantepiphany:  I totally feel your pain ? been there and cried at that
[20:39:41] <kcbabo> errantepiphany:  and to your question above ? "So in the case of CompositeServices and CompositeReferences, a promote attribute is either "componentName" or "componentName/serviceName" (or "componentName/referenceName")"
[20:39:45] <kcbabo> errantepiphany:  the answer is yes
[20:40:07] <kcbabo> errantepiphany:  not sure if we handle the component name only case (i.e. single service/reference) case at this point
[20:40:10] <kcbabo> errantepiphany:  maybe another JIRA there
[20:40:16] <errantepiphany> kcbabo: no, we do.
[20:40:30] <kcbabo> errantepiphany:  great ? I love pleasant surprises :-)
[20:40:51] <errantepiphany> kcbabo: the bug was that we don't handle the nested service underneath the component - even though we do handle the nested reference underneath the component.
[20:41:13] <errantepiphany> kcbabo: ie: CompositeReferenceModel was correct, but CompositeServiceModel was not.
[20:41:34] <errantepiphany> kcbabo: (rather, their V1 impls)
[20:43:02] *** bobmcw has quit IRC
[20:46:17] <kcbabo> errantepiphany:  ah, ok
[20:52:04] <rcernich> kcbabo: ping
[20:52:32] <kcbabo> rcernich:  hey
[20:52:57] <rcernich> kcbabo: how are you doing?
[20:53:18] <kcbabo> rcernich:  not bad, how are you feeling?
[20:54:08] <rcernich> kcbabo: better.  lungs are clear.  need to get another chest xray in a couple of weeks to make sure it's gone for good.
[20:54:24] <rcernich> kcbabo: wife is sick now, not in her chest though, so that's good
[20:54:31] <kcbabo> rcernich:  well, that's a major improvement
[20:54:34] <kcbabo> rcernich:  oh no!
[20:54:41] <rcernich> kcbabo: what can you do?
[20:54:50] <rcernich> kcbabo: couple quick questions
[20:54:54] <kcbabo> rcernich:  sure thing
[20:55:19] <rcernich> kcbabo: i've figured out how to "tag" switchyard app's through the dmr mechanism
[20:55:28] <kcbabo> rcernich:  cool
[20:55:35] <rcernich> kcbabo: and i'm looking at getting the config
[20:55:43] <rcernich> kcbabo: now the questions...
[20:56:14] <rcernich> kcbabo: the SwitchYardService hides the backing SwitchYardDeployment
[20:56:35] <rcernich> kcbabo: i.e. getValue() always returns null, as opposed to the backing deployment
[20:56:58] <kcbabo> rcernich:  hmm ? not sure if that was deliberate or not
[20:57:07] <kcbabo> rcernich:  magesh wrote that, so he would be the best person to ask
[20:57:26] <rcernich> kcbabo: ok.  the other question was about the Deployment object itself
[20:57:52] <rcernich> kcbabo: getConfig() was declared with package scope
[20:58:10] <rcernich> kcbabo: so, two hurdles to get to the config
[20:58:28] <rcernich> kcbabo: i'll send magesh an email asking him about it
[20:58:47] <rcernich> kcbabo: i'm assuming it was to keep out the riff raff (like me;))
[20:59:26] <rcernich> kcbabo: anyway, with a couple of minor changes, i should be able to get some switchyard info into the console rather quickly
[20:59:30] <kcbabo> rcernich:  hehe ? so that package-scoped getConfig() was most likely for test purposes more than anything else
[20:59:52] <rcernich> kcbabo: ahh.  makes sense.
[21:00:27] <rcernich> kcbabo: access to those allows the user to start/stop the switchyard service (which delegates to deployment)
[21:00:35] <kcbabo> rcernich:  so up until now, we have not dedicated any think time to how this information would be queried in management tools
[21:00:40] <rcernich> kcbabo: and the config allows the user to muck it up
[21:00:51] <rcernich> kcbabo: right
[21:01:01] <rcernich> kcbabo: i was just moving along the dmr path
[21:01:08] <kcbabo> rcernich:  so I think it would make sense to walk through the basic use cases of what we would like to do from a management/monitoring standpoint
[21:01:18] <rcernich> kcbabo: which, as i understand it, should also be accessible through mbeans
[21:01:29] <kcbabo> rcernich:  and then most likely cut out a set of interfaces that you can interact with
[21:01:42] <rcernich> kcbabo: e.g. creating read-only APIs?
[21:02:11] <kcbabo> rcernich:  it doesn't necessarily have to be read-only
[21:02:19] <rcernich> kcbabo: i'll create a discussion topic
[21:02:53] <rcernich> kcbabo: for the time being, i can muck around in my workspace
[21:02:58] <kcbabo> rcernich:  that would be great
[21:03:18] <kcbabo> rcernich:  I think the direct route that you're exploring right now is good
[21:03:42] <kcbabo> rcernich:  just saying that don't treat what's there as concrete
[21:03:44] <rcernich> kcbabo: fyi, currently the dmr route allows you to use the jboss-admin cli for queries as well
[21:03:53] <rcernich> kcbabo: understood
[21:04:09] <kcbabo> rcernich:  it's more of a poorly formed jello mound ;-)
[21:04:25] <kcbabo> rcernich:  right, so I think that's attractive with DMR
[21:04:30] <rcernich> kcbabo: as long as it doesn't have too many chunks;)
[21:04:46] <rcernich> kcbabo: especially cat food (a la christmas vacation)
[21:05:01] <kcbabo> rcernich:  hehe ? not quite that bad
[21:05:30] <rcernich> kcbabo: e.g. /deployment=switchyard-quickstart-demo-orders-0.1.0-SNAPSHOT.jar/subsystem=switchyard/:read-services
[21:06:54] <rcernich> kcbabo: the "subsystem=switchyard" identifies the deployment as a switchyard application
[21:07:40] <rcernich> kcbabo: the read-services operation is added to that path (i.e. deployment=<package-name>/subsystem=switchyard)
[21:08:14] <kcbabo> rcernich:  makes sense
[21:08:37] <rcernich> kcbabo: i'll hash out a crude design an post it on jboss.org
[21:09:11] <rcernich> kcbabo: since dmr will provide a json like view of the configuration data
[21:09:56] <rcernich> kcbabo: it would be good to have some extra eyeballs on the api design (e.g. read-services)
[21:10:05] <rcernich> kcbabo: i'll leave you be
[21:10:09] <rcernich> kcbabo: thanks for the info
[21:10:29] <kcbabo> rcernich:  json view of the config data?
[21:10:48] <rcernich> kcbabo: that's kind of what you get from dmr
[21:11:14] <rcernich> kcbabo: nested sets of key/value pairs
[21:11:57] <kcbabo> rcernich:  I'm wondering how the XML description of our app will map to JSON in that case
[21:12:20] <kcbabo> rcernich:  for example, can you pull out a HornetQ queue definition via the DMR API?
[21:12:29] <kcbabo> rcernich:  or is it some other metadata?
[21:12:32] <rcernich> kcbabo: you should be able to
[21:12:42] <kcbabo> rcernich:  I think that would be an interesting point of reference
[21:12:49] <rcernich> kcbabo: for sure, anything in the config file is exposed through dmr
[21:13:07] <kcbabo> rcernich:  which "config" file are you referring to though?
[21:13:18] <rcernich> kcbabo: e.g. standalone.xml
[21:13:18] <kcbabo> rcernich:  switchyard.xml?
[21:13:26] <rcernich> kcbabo: as config file
[21:13:36] <kcbabo> rcernich:  ok, so that's where I zigged and you zagged :-)
[21:13:48] <rcernich> kcbabo: possibly
[21:14:00] <kcbabo> rcernich:  so you can pull the application definition out of there
[21:14:10] <rcernich> kcbabo: sort of
[21:14:18] <kcbabo> rcernich:  but all the interesting details about that application are not going to be in standalone.xml
[21:14:29] <kcbabo> rcernich:  they are going to be in switchyard.xml in the application archive
[21:14:56] <rcernich> kcbabo: exactly, hence the need to access SwitchYardModel
[21:15:24] <kcbabo> rcernich:  right, which is where I was coming from with my question of how the switchyard config which is serialized as XML will be mapped to a JSON model
[21:15:25] <rcernich> kcbabo: which i can do programatically
[21:15:36] <rcernich> kcbabo: yes
[21:15:58] <kcbabo> rcernich:  so I guess you could construct some intermediate objects by querying the config and returning those as JSON
[21:16:03] <rcernich> kcbabo: it should also be possible to simply return the xml
[21:16:23] <rcernich> kcbabo: well, i hadn't given it much thought, but that's the direction i've been heading
[21:16:27] <kcbabo> rcernich:  or we could look at a JSON serialization of the config using a JSON marshaller
[21:16:30] <rcernich> kcbabo: just to get something up and running
[21:16:37] <rcernich> kcbabo: i don't mind throwing any of this away
[21:16:40] <kcbabo> rcernich:  yeah, that's fine
[21:16:46] <kcbabo> rcernich:  just thinking out loud here
[21:16:57] <rcernich> kcbabo: no, that's good.
[21:17:06] <rcernich> kcbabo: i've only recently started pondering it
[21:17:07] <kcbabo> rcernich:  wondering whether the XML or JSON would be more useful from a client standpoint
[21:17:22] <kcbabo> rcernich:  my guess would be that JSON would be easier to consume from webui type stuff
[21:17:23] <rcernich> kcbabo: there may be some issues on the gwt side
[21:18:04] <rcernich> kcbabo: i'd have to figure out how to parse the thing, or create something to render it appropriately (e.g. special style sheets)
[21:18:28] <rcernich> kcbabo: with gwt, java stuff needs to be compiled into java script that runs in the browser
[21:18:54] <kcbabo> rcernich:  I thought it was easy to populate a screen with JSON data in GWT?
[21:18:55] <rcernich> kcbabo: so there are some limits as to what you can use, and the more you use, the more js, the bigger the app
[21:19:08] <kcbabo> rcernich:  of course, I'm completely useless when it comes to UI so keep that in mind
[21:19:10] <rcernich> kcbabo: i'm still learning:)
[21:19:37] <rcernich> kcbabo: i've been doing gwt for about three or four weeks now:)
[21:19:53] <kcbabo> rcernich:  well, I'm sure the AS7 console would provide a nice example of why it works well or doesn't
[21:20:11] <kcbabo> rcernich:  since I'm sure it's just a GWT overlay on top of DMR
[21:20:17] <rcernich> kcbabo: and it's built entirely atop dmr
[21:20:24] <kcbabo> rcernich:  well, I shouldn't say I'm sure ?. I would guess
[21:20:31] <rcernich> kcbabo: no, that's correct
[21:20:54] <rcernich> kcbabo: although, there are models for the "business" objects
[21:21:23] <rcernich> kcbabo: so there's a manual parse to populate the bean objects from the json (dmr) data
[21:21:38] <rcernich> kcbabo: but now you've got me thinking
[21:21:45] <rcernich> kcbabo: i'll see if there isn't an easier way
[21:21:56] <rcernich> kcbabo: because that's a lot of code to write
[21:22:24] <kcbabo> rcernich:  coolio
[21:22:27] <rcernich> kcbabo: i'd also like to get rid of the dmr servlet
[21:22:40] <rcernich> kcbabo: since gwt should be able to handle that through a service interface
[21:23:01] <rcernich> kcbabo: one less moving part
[21:31:28] <antollinim> rcernich: maybe I can help, you need a glue code to integrate GWT UI objects to backend objects?
[21:31:47] <rcernich> antollinim: hey
[21:31:47] <antollinim> rcernich: if I did not understand wrong...
[21:32:24] <rcernich> antollinim: probably more the other way round at this point
[21:32:47] <rcernich> antollinim: although once i start working on a "designer" i'll probably be going both ways
[21:33:06] <antollinim> rcernich: some time ago I found sth like that, let me research a little bit
[21:33:11] <rcernich> antollinim: right now, data that comes from the dmr interface is formatted basically as json data
[21:33:40] <rcernich> antollinim: which i'm currently forming into beans on the client side
[21:33:58] <rcernich> antollinim: i haven't done too much research into it at this point
[21:34:04] <antollinim> rcernich: so you already have that working?
[21:34:08] <rcernich> antollinim: just been going off what's being done in the as console
[21:34:20] <rcernich> antollinim: just a very crude bit
[21:34:46] <rcernich> antollinim: e.g. the "modules" section in the as config for the switchyard subsystem
[21:35:18] <antollinim> rcernich: anyway, I can pinpoint you that, you can use it if you consider it is suitable
[21:35:24] <rcernich> antollinim: and the deployments (i.e. package name, etc.; much like the as console itself)
[21:35:34] <rcernich> antollinim: that would be awesome
[21:35:37] <rcernich> antollinim: thanks!
[21:36:15] <rcernich> antollinim: i think as console folks are trying to standardize on autobean
[21:36:27] <rcernich> antollinim: for their data objects
[21:36:54] <rcernich> antollinim: which they munge to and from the dmr interface
[21:36:54] <antollinim> rcernich: sounds good
[21:37:20] <errantepiphany> kcbabo: Have you noticed all the switchyard-release tests are failing?
[21:37:49] <rcernich> antollinim: but, as keith and i were talking, things get more complicated when you start looking at exposing switchyard.xml as json
[21:37:54] <errantepiphany> kcbabo: Caused by: java.lang.IllegalArgumentException: Path to the pom.xml file must be defined and accessible
[21:38:16] <antollinim> rcernich: indeed
[21:38:20] <kcbabo> errantepiphany:  last build looks good to me
[21:38:21] <kcbabo> http://ci.jboss.org/jenkins/job/SwitchYard-Release/
[21:38:33] <kcbabo> errantepiphany:  but there were a bunch of failures in a row before that
[21:38:39] <kcbabo> errantepiphany:  as magesh cleaned up my mess ;-)
[21:40:34] <errantepiphany> hmmmm
[21:48:22] <rcernich> antollinim: is this what you were referring to?  http://code.google.com/webtoolkit/articles/using_gwt_for_json_mashups.html
[21:49:49] <antollinim> rcernich: I am looking for actual code wich works and someone shared. I could not find it yet
[21:50:12] <rcernich> antollinim: cool.  you and keith got me thinking.
[22:02:31] *** kcbabo has quit IRC
[22:08:47] *** ldimaggi_ has joined #switchyard
[22:12:08] *** ldimaggi has quit IRC
[22:13:06] <antollinim> rcernich: couldn't find it :(. I might have a pointer in my other computer. I'll take a look at it when I get home. Sorry for that
[22:13:20] <rcernich> antollinim: no worries.  thanks for looking.
[22:24:23] *** errantepiphany has left #switchyard
[23:10:25] *** ldimaggi_ has quit IRC
[23:10:59] *** errantepiphany has joined #switchyard





top