Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+[03:36:27] <saltuk> hi there  .. i didnt know about    vertx.getOrCreateContext() before see it on jdbc-client   so  this logic on  http://codepaste.net/si872f will work or do i need to something different ? ...
+[09:41:13] <purplefox> hi AlexLehm
+[10:12:48] <purplefox> temporalfox: hi julien
+[10:12:54] <temporalfox> hi purplefox
+[10:12:58] <purplefox> temporalfox: good weekend?
+[10:13:25] <temporalfox> purplefox good, resting a little was good for me :-)
+[10:13:47] <purplefox> it's important  :)
+[10:14:04] <temporalfox> purplefox ready for the last milestone ?
+[10:14:36] <purplefox> getting prepared for it. let's have a little meeting in a while to discuss what remains to be done
+[10:14:54] <temporalfox> ok
+[10:15:00] <purplefox> how about 11am (my time) - i.e. in 1 hr 45
+[10:15:28] <temporalfox> can we have it a bit earlier ?
+[10:21:10] <purplefox> ok, how about at 9:45?
+[10:21:14] <purplefox> (25 mins)
+[10:22:53] <temporalfox> ok good
+[10:24:13] <purplefox> temporalfox: btw, if you can think of any good names to rename Apex to, that's something to think about
+[10:24:26] <temporalfox> purplefox I'm really bad at finding names :-)
+[10:24:38] <purplefox> it's difficult
+[10:24:58] <temporalfox> it's a job for some :-)
+[10:25:10] <purplefox> i'm thinking of variations around the theme of "vert.x", "web", "microservice" and "boot"
+[10:25:25] <temporalfox> vertx woot :-) ?
+[10:25:35] <purplefox> lol.
+[10:25:45] <purplefox> or microvertxwebboot?
+[10:26:01] <purplefox> actually woot is not too bad...
+[10:28:47] <purplefox> temporalfox: what about "microbe" ?
+[10:29:01] <purplefox> it's small. it's got micro in it ,and a b for boot?
+[10:29:40] <temporalfox> microbe in french is not really sexy
+[10:30:07] <purplefox> i guess it's a bit like "bacteria" ? ;)
+[10:30:12] <temporalfox> exactly
+[10:30:51] <purplefox> micrex?
+[10:31:09] <purplefox> voot?
+[10:32:13] <temporalfox> not really
+[10:32:31] <purplefox> vapex?
+[10:33:04] <temporalfox> webex ?
+[10:33:09] <purplefox> lol. nooooo!
+[10:33:33] <purplefox> vicro?
+[10:34:04] <temporalfox> vertx factor
+[10:34:37] <pmlopes> what about load? it is kind of a synonym to boot
+[10:35:08] <purplefox> load can also mean to make something heavy
+[10:35:16] <purplefox> i.e. not lightweight
+[10:35:50] <purplefox> what about xepa? (apex backwards)
+[10:36:04] <temporalfox> not good
+[10:36:47] <pmlopes> xerpa
+[10:38:03] <temporalfox> vertx spine ?
+[10:38:16] <purplefox> carob
+[10:38:42] <purplefox> ok keep em coming
+[10:39:15] <purplefox> pmlopes: julien and i are going to discuss remaining  tasks for V3 in a little while.. feel free to join in if you like :)
+[10:40:24] <millrossjez> vertx-sherpa :)
+[10:40:43] <purplefox> vertx - sherpa - it helps you climb mountains ;)
+[10:40:51] <purplefox> yeah not bad
+[10:40:57] <temporalfox> vertx face :-)
+[10:41:12] <pmlopes> or: brink
+[10:46:06] <temporalfox> vertx flow
+[10:46:08] <temporalfox> vertx path
+[10:50:10] <purplefox> how about - in node.js there is express project, and espresso is a small coffee, so how about doppio? (double espresso?)
+[10:50:21] <purplefox> and coffee is java of course
+[10:51:15] <temporalfox> it's also a JVM in coffeescript
+[10:51:17] <temporalfox> Doppio: A JVM in Coffeescript
+[10:51:22] <temporalfox> besides that I like it
+[10:51:42] <temporalfox> and there is potential for a good logo
+[10:52:04] <temporalfox> (with the coffee cream, etc...)
+[10:52:05] <purplefox> yeah. a jvm in coffeescript may be far enough removed not to be an issue
+[10:52:52] <purplefox> hmmm seems fairly popular actually :(
+[10:52:55] <purplefox> 706 stars
+[10:53:03] <purplefox> https://github.com/plasma-umass/doppio
+[10:53:59] <purplefox> ok... anyway let's keep thinking
+[10:54:07] <purplefox> but let's get on with the meeting now
+[10:54:21] <purplefox> how about we just go through each project one by one, and see what is outstanding?
+[10:54:52] <temporalfox> I'mready for meeting
+[10:55:00] <temporalfox> good idea
+[10:55:13] <purplefox> ok let's start with core
+[10:55:58] <temporalfox> I would like to have simple metrics tests that check context / thread and then clarify the behavior in the spi doc
+[10:56:19] <purplefox> ok, makes sense
+[10:56:21] <temporalfox> because callbacks will have different thread depending on the metric part
+[10:56:31] <temporalfox> and that should be clear for the spi implementor what to expect
+[10:56:50] <purplefox> agreed
+[10:57:12] <purplefox> also there are a few gaps in the docs in general, but other than that I don't think there is any significant work to do
+[10:57:17] <temporalfox> other thing
+[10:57:29] <temporalfox> I would like to have a WriteStream.end()
+[10:57:39] <temporalfox> corresponding to onComplete()
+[10:57:44] <temporalfox> that say no more event will come
+[10:58:04] <purplefox> is this what we discussed before?
+[10:58:06] <temporalfox> makes implementation for rx / reactive-streams better
+[10:58:11] <temporalfox> yes but it was less clear :-)
+[10:58:18] <temporalfox> now I know it should mean "no more event"
+[10:58:30] <temporalfox> and we do have this in ReadStream#endHandler
+[10:58:42] <temporalfox> and actually I think node.js does have it in WriteStream
+[10:58:56] <purplefox> sec, brb 3 mins
+[11:01:07] <purplefox> ok back, door
+[11:01:27] <purplefox> ok that makes sense to add that method
+[11:01:49] <temporalfox> ^^
+[11:02:15] <purplefox> anything else on core?
+[11:03:10] <temporalfox> I don't see anything outstanding right now
+[11:03:27] <purplefox> Alright.. let's do web-site next
+[11:03:41] <temporalfox> really :-) ?
+[11:03:55] <temporalfox> I find the actual website very good
+[11:03:57] <purplefox> why not?
+[11:04:20] <temporalfox> I believe a blog would be good
+[11:04:28] <temporalfox> I mean I want to write things about vertx
+[11:04:35] <temporalfox> and I don't want to do it on my own blog
+[11:04:44] <purplefox> Agreed, but I'm not sure it is a priority for 3.0
+[11:04:48] <temporalfox> ok
+[11:04:52] <purplefox> i'll add it to the list anyway
+[11:05:06] <purplefox> The content on the front page needs some tweaks
+[11:05:28] <purplefox> The community page needs completing with contributors
+[11:06:03] <temporalfox> yes but I think that there is some wip about that
+[11:06:06] <purplefox> Who's using vert.x stuff needds to be completed
+[11:06:12] <temporalfox> using a json structure to generate contributor page
+[11:06:38] <purplefox> yeah, but it still needs completing :)
+[11:06:48] <purplefox> basically anything that needs to be done goes on the list
+[11:07:21] <purplefox> I want to get an overall picture of everthing that needs to be done before 3.0
+[11:07:26] <temporalfox> ok
+[11:07:55] <purplefox> but agreed, the website is great :) thanks to michel
+[11:08:48] <purplefox> i think the docs page could be tweaked a bit but is more or less there
+[11:10:14] <purplefox> only 4 contributors have actually submitted their details so far so maybe we will have to be more proactive
+[11:10:25] <temporalfox> ok
+[11:10:34] <purplefox> pmlopes: millrossjez what about you guys?
+[11:10:43] <temporalfox> I think michel is doing some kind of json -> html generator for contributors
+[11:11:16] <purplefox> yeah
+[11:11:53] <purplefox> i think what we should also do is write a little script that uses the github rest api to get a list of all contributors for all projects and their github ids then we can create some html for that
+[11:12:28] <purplefox> otherwise it looks like we only have 4 contribs, when the truth is we probably have over a hundred (i would guess)
+[11:12:34] <temporalfox> I remember back in the days we put randomly a contributor on the front page on jboss.org site
+[11:12:54] <purplefox> ah yes i remember that :)
+[11:13:59] <pmlopes> @purplefox yes you can add me to the list
+[11:14:23] <pmlopes> i also asked at work for being listed but did not get any feedback on that
+[11:16:30] <purplefox> pmlopes: ok, np. can you submit a pr as per https://groups.google.com/forum/?fromgroups#!topic/vertx/_rlRE6FViNA ?
+[11:19:50] <purplefox> ok, anything else on website?
+[11:20:55] <temporalfox> I don't see anything outstanding now
+[11:21:36] <purplefox> ok, let's do apex next
+[11:21:53] <temporalfox> ok
+[11:21:59] <purplefox> the main thing here is the WIP refactoring to the auth/session stuff
+[11:22:08] <temporalfox> I followed that on the list indeed
+[11:22:16] <purplefox> which stephane is looking at. pmlopes are you looking at this too?
+[11:23:14] <purplefox> so basically that's an important thing that needs completing, because we don't want to change major interfaces after 3.0 is out
+[11:23:34] <purplefox> i will chase that up with stephane today
+[11:23:47] <temporalfox> I agree
+[11:24:51] <pmlopes> Stephane was supposed to deliver his WIP but i haven't heard from him yet, i mailed him during the weekend but again no success...
+[11:25:23] <purplefox> paulo, it would be great if you could review it, as I want to be sure it fulfills your requirements too, and looks correct :)
+[11:28:13] <purplefox> ah shit, my back button has just failed on my keyboard :(
+[11:30:53] <purplefox> there are a few other smaller bugs/issues in apex, but nothing else major
+[11:32:13] <purplefox> ok.. codegen next
+[11:32:22] <purplefox> temporalfox: can you think of anything major outstanding?
+[11:33:09] <temporalfox> codegen there is this PR for List<DataObject>
+[11:33:17] <temporalfox> contribution
+[11:33:28] <temporalfox> and I'm driving the guy to finish it
+[11:33:35] <temporalfox> (lack of TCK / lang tests)
+[11:33:50] <temporalfox> let me look at the open issues
+[11:33:51] <purplefox> is that needed for 3.0?
+[11:34:27] <temporalfox> that would allow I htink better interfaces
+[11:34:38] <temporalfox> I mean better apis
+[11:34:41] <temporalfox> and that is contributed
+[11:34:56] <purplefox> is there a use case for this?
+[11:35:37] <temporalfox> not of my own
+[11:35:51] <temporalfox> https://github.com/vert-x3/vertx-codegen/pull/30
+[11:36:41] <purplefox> ok, with something like this-- I think it is good, but I don't think we should spend a lot of time on it ourselves because there is other more important stuff. but if the contibutor is doing all the work that's fine :)
+[11:37:33] <purplefox> pmlopes: stephane has just posted on the google group about the session/auth stuff
+[11:38:18] <temporalfox> personally the only feature I would honor is that one : https://github.com/vert-x3/vertx-codegen/issues/29
+[11:38:21] <temporalfox> Expose a structured ParamInfo.description
+[11:38:27] <temporalfox> to generate better documentation
+[11:38:31] <temporalfox> at the moment if we have
+[11:38:58] <temporalfox> @param foo the foo {@link io.vertx.core.streams.ReadStream}
+[11:39:04] <temporalfox> that will be opaque and not rewritten
+[11:39:17] <temporalfox> it was raised on the forum by the latest scala contributor
+[11:39:35] <temporalfox> it's not big deal
+[11:39:38] <temporalfox> minor
+[11:40:24] <purplefox> ok
+[11:41:33] <purplefox> alright, next: docgen
+[11:41:38] <purplefox> anything to do there?
+[11:41:45] <temporalfox> I don't see any issue in docgen
+[11:43:00] <purplefox> great
+[11:43:05] <purplefox> ok next: vertx-stack
+[11:43:16] <purplefox> for me the big thing here is I think we should have multiple distros
+[11:43:21] <temporalfox> yes
+[11:43:35] <temporalfox> and also integrate docker here somehow
+[11:43:36] <purplefox> and we also need to analyse the dependencies to make sure we are not pulling in unnecessary thibngs
+[11:43:49] <purplefox> yes
+[11:44:01] <temporalfox> purplefox we should actually have a blacklist approach for dependencies
+[11:44:05] <temporalfox> and allow only some
+[11:44:18] <temporalfox> instead of being permitive
+[11:44:46] <purplefox> do you mean a blacklist or whitelist?
+[11:44:52] <temporalfox> a whitellist
+[11:44:55] <purplefox> i agree
+[11:45:00] <temporalfox> exclude non io.vertx jars
+[11:45:10] <temporalfox> and include explicitly the ones we need
+[11:45:13] <temporalfox> per distrib
+[11:45:27] <purplefox> yes, and if the build attempts to pull in one that is not on the list the build should fail
+[11:45:53] <temporalfox> purplefox I don't know if that's trivial to do
+[11:47:02] <purplefox> in maven it's probably tricky - but maybe we could write a script to do it, and just call that from the build?
+[11:47:32] <temporalfox> purplefox yes somehow like
+[11:47:33] <temporalfox> this
+[11:47:38] <temporalfox> need to see
+[11:48:04] <purplefox> so let's discuss for a bit which distros we would like
+[11:48:16] <purplefox> i am thinking:
+[11:48:32] <temporalfox> I think we should also define per distro the corresponding depchain
+[11:48:41] <purplefox> ok
+[11:48:47] <temporalfox> so people can use corresponding depchain to bring in everything they need but with a scope
+[11:49:03] <purplefox> yes
+[11:49:21] <purplefox> so what dists do we want?
+[11:49:29] <purplefox> 1. "all" - containing everything
+[11:49:30] <temporalfox> we should ask maybe on the list :-)
+[11:49:38] <temporalfox> all / minimal are the obvious ones
+[11:49:43] <purplefox> yes, lets post about it there too
+[11:49:47] <purplefox> agreed
+[11:49:49] <temporalfox> then at least one without messaging / jcr / etc...
+[11:49:51] <temporalfox> jca
+[11:50:05] <temporalfox> i.e like data + web
+[11:50:09] <purplefox> i think jca should never be in the dist as its something you install in the app server
+[11:50:14] <temporalfox> ah yes indeed
+[11:50:16] <temporalfox> good point :-)
+[11:51:11] <purplefox> and i think one per language
+[11:51:24] <temporalfox> yes
+[11:52:49] <purplefox> ok, would you like to post a suggestion on the google group about this and see what people suggest?
+[11:53:17] <temporalfox> ok I will
+[11:53:18] <purplefox> we don't want _too many_ distros, so it's kind of tricky
+[11:53:37] <purplefox> maybe somethings should never be included and users have to explicitly add them...
+[11:56:58] <purplefox> ok next is service-proxy
+[11:57:06] <purplefox> i think there is nothing outstanding there
+[11:57:13] <temporalfox> there is a corresponding PR for List<DataObject>
+[11:57:19] <temporalfox> contribution
+[11:57:25] <temporalfox> needs to be reviewed
+[11:57:27] <purplefox> yes
+[11:57:42] <temporalfox> beside that I don't see anything to do
+[11:58:36] <purplefox> ok
+[11:58:41] <purplefox> next vertx-hazelcast
+[11:58:55] <purplefox> there is currently a major ouststanding hazelcast bug
+[11:59:14] <temporalfox> I believe you :-)
+[12:03:09] <purplefox> https://github.com/hazelcast/hazelcast/issues/5220
+[12:03:19] <temporalfox> ok
+[12:03:47] <purplefox> if they don't fix it before 3.0 then we are going to have to do some major work in the way clustering is done to workaround it
+[12:04:02] <purplefox> which would probably take several days
+[12:04:07] <purplefox> so that is a risk
+[12:04:22] <temporalfox> I see...
+[12:04:26] <temporalfox> no control
+[12:06:03] <purplefox> ok next, http-service-factory
+[12:06:41] <temporalfox> port the 2.x client features : redirection + bintray tutorial
+[12:06:57] <purplefox> i am sure it all works perfectly ;) but as a user if i come to this site https://github.com/vert-x3/vertx-http-service-factory it doesn't really tell me what it is for or how to use it
+[12:07:10] <purplefox> so this is a mystery to me
+[12:07:19] <temporalfox> there is doc in the project itself
+[12:07:29] <purplefox> there is a broken link on the readme
+[12:07:36] <temporalfox> http://vert-x3.github.io/docs/vertx-http-service-factory/
+[12:07:42] <temporalfox> ok
+[12:08:04] <purplefox> I get a 404 on the docs link on the front page
+[12:08:33] <temporalfox> ok
+[12:09:13] <purplefox> ok i can see the actual docs now, and they look good
+[12:09:54] <temporalfox> fixed :-)
+[12:12:13] <purplefox> ok. maven-service-factory
+[12:12:18] <purplefox>  i think we are all good there?
+[12:12:26] <temporalfox> yes
+[12:12:42] <temporalfox> overally I think in the next iteration 3.1 there can be improvments
+[12:12:49] <temporalfox> but for 3.0 it's fit the needs
+[12:13:18] <purplefox> vertx-reactive-streams
+[12:13:26] <purplefox> i think we are good there too?
+[12:14:19] <temporalfox> we need to see if there is something to do with WriteStream#end
+[12:14:30] <purplefox> ok
+[12:14:32] <temporalfox> and probably there is
+[12:18:31] <millrossjez> purplefox: I will be submitting my contrib info, pitiful though my contribs are so far, was waiting for that json generator. I'm probably the smallest contributor so far :)
+[12:20:36] <purplefox> it all counts :)
+[12:21:59] <temporalfox> millrossjez size does not matter
+[12:23:40] <purplefox> lol
+[12:23:55] <aesteve> hello everyone :)
+[12:23:58] <purplefox> hi
+[12:24:05] <aesteve> so for apex release : only session/auth ?
+[12:24:19] <purplefox> aesteve: that's the major thing, yes
+[12:24:55] <aesteve> ok nice to have a view on the release plan
+[12:25:31] <purplefox> ok. vertx-rx
+[12:25:38] <purplefox> temporalfox: anytihng to do there?
+[12:25:41] <temporalfox> yes
+[12:25:49] <temporalfox> finish the reactive-streams rebase in progress
+[12:26:15] <temporalfox> possibly provide an Observer for WriteStream
+[12:26:23] <temporalfox> I started some work actually on this a while ago
+[12:26:55] <temporalfox> and I do have the code locally
+[12:27:05] <temporalfox> need to see how it fits with reactive streams
+[12:27:14] <temporalfox> overally
+[12:27:21] <temporalfox> with vertx core / vertx-rx and reactive streams
+[12:27:24] <temporalfox> it's related work
+[12:27:25] <purplefox> this is for back pressure?
+[12:27:30] <temporalfox> and I would like to have a proper closure
+[12:27:37] <temporalfox> on these
+[12:27:51] <temporalfox> so primarly the feature was not back pressure
+[12:28:03] <temporalfox> but how to turn a WriteStream -> rx Observer
+[12:28:14] <temporalfox> like we do have for ReadStream -> Observable
+[12:28:31] <temporalfox> now if we rely on reative streams
+[12:28:34] <temporalfox> to do the bridge
+[12:28:38] <temporalfox> we have back pressure
+[12:29:04] <temporalfox> so at the end someone
+[12:29:09] <purplefox> i guess i still don't understand why writestream needs to be an observer
+[12:29:24] <temporalfox> because you can subscrive it to an Observable
+[12:29:57] <temporalfox> you can take a file and subscribe it to an HttpServerRequest
+[12:30:29] <temporalfox> request.toObserable().subscribe(file.toObserver())
+[12:30:48] <purplefox> and that is supposed to do back pressure too?
+[12:30:52] <temporalfox> yes
+[12:31:10] <temporalfox> since Observer will get the Subscription
+[12:31:18] <temporalfox> and Subscription has a request(n) method
+[12:31:48] <temporalfox> we can delay that to 3.1 if you feel more comfortable
+[12:31:51] <temporalfox> Observer par
+[12:31:53] <temporalfox> part
+[12:32:10] <temporalfox> I agree that we would not have feedback on it like we had for Observable
+[12:35:08] <purplefox> this confuses me as it seems to be back to front
+[12:35:22] <temporalfox> ok let's skip it :-)
+[12:35:34] <temporalfox> and focus on getting proper Observable / back pressure support
+[12:35:48] <purplefox> for example here is vertx-reactive-streams
+[12:35:49] <purplefox> https://github.com/vert-x3/vertx-reactive-streams/blob/master/src/main/java/examples/ReactiveStreamsExamples.java#L48
+[12:36:07] <purplefox> and this is about pumping a server request to a file, just like your example
+[12:36:32] <temporalfox> ok
+[12:36:37] <purplefox> in this case the file subscribes to the request
+[12:36:40] <purplefox> which makes sense
+[12:36:46] <purplefox> as the file receives data from the request
+[12:37:04] <purplefox> but in your example, it's the other way around, which i don't understand
+[12:37:07] <temporalfox> I think that if we do use reative-streams for implementing RxJava
+[12:37:17] <temporalfox> we do have double pumping
+[12:37:35] <temporalfox> credits -> request -> credits
+[12:38:19] <purplefox> i'm talking about flow of data here
+[12:38:20] <purplefox> not credits
+[12:38:52] <purplefox> i don't see why a request would subscribe to a file if the data is flowing in the other direction
+[12:39:18] <temporalfox> ok
+[12:39:27] <purplefox> anyway, yeah lets leave this to 3.1 because I am confused ;)
+[12:39:48] <temporalfox> it's terminolgy
+[12:39:56] <temporalfox> in RxJava Observable.subscribe(observer)
+[12:40:05] <temporalfox> means I subscribe an Observer to an Observable
+[12:40:14] <temporalfox>     public final Subscription subscribe(Subscriber<? super T> subscriber) {
+[12:40:18] <temporalfox> on Observable
+[12:40:35] <temporalfox> agreed we should skip
+[12:40:47] <purplefox> i think it means the same (more or less) in reactive streams
+[12:41:05] <purplefox> but subscribers *receive data*
+[12:41:05] <temporalfox> let's go on :-)
+[12:41:10] <temporalfox> yes
+[12:41:23] <temporalfox> HttpServerRequest is an Observable<Buffer>
+[12:41:35] <temporalfox> File can be an Observer<Buffer> (for writing)
+[12:42:12] <purplefox> hmmm not sure about that
+[12:42:48] <temporalfox> I need to go to lunch soon :-)
+[12:42:50] <purplefox> ok let's skip this
+[12:44:38] <purplefox> when do you need to go to lunch?
+[12:44:54] <temporalfox> 15mn max
+[12:45:15] <purplefox> ok let's see if we can be quick:
+[12:45:19] <purplefox> mail-client:
+[12:45:32] <purplefox> basically waiting for alex to make some changes and docs to be done
+[12:45:33] <temporalfox> you know better than me
+[12:45:37] <temporalfox> ok
+[12:46:00] <purplefox> jdbc-client:
+[12:46:09] <purplefox> all good i think
+[12:46:13] <temporalfox> yes
+[12:46:21] <purplefox> mysql-postgres:
+[12:46:22] <purplefox> all good
+[12:46:41] <purplefox> vertx-mongo
+[12:46:44] <purplefox> all good
+[12:46:51] <temporalfox> data services look good
+[12:46:55] <temporalfox> I mean
+[12:46:58] <temporalfox> data clients :-)
+[12:47:04] <purplefox> vertx-redis:
+[12:47:07] <purplefox> needs docs
+[12:47:23] <temporalfox> yes
+[12:47:37] <purplefox> vertx-rabbitmq -- need to look at this
+[12:47:42] <purplefox> not sure what is there yet
+[12:47:53] <temporalfox> ok
+[12:48:05] <purplefox> and same with vertx-amqp
+[12:48:13] <temporalfox> ok
+[12:48:38] <purplefox> where are we with vertx-lang-ruby?
+[12:48:50] <temporalfox> missing specific documentation
+[12:49:01] <temporalfox> specific ruby documentation
+[12:49:10] <temporalfox> besides I think it's good looking
+[12:49:20] <purplefox> does codetrans work with it?
+[12:49:22] <temporalfox> I hope we get feedback with milestone5
+[12:49:28] <temporalfox> purplefox yes but it is not perfect
+[12:49:38] <temporalfox> I tested with core examples and theyr owrk
+[12:49:43] <temporalfox> they allowed me to fix bugs
+[12:49:53] <temporalfox> I need to try apex examples
+[12:49:59] <temporalfox> and see if they pass
+[12:50:06] <temporalfox> there is one issue I tink at least in codetrans
+[12:50:13] <temporalfox> the "x++"
+[12:50:21] <temporalfox> that does not have equivalent in ruby
+[12:50:29] <temporalfox> so I'm considering banning it
+[12:50:32] <temporalfox> and use instead ++x
+[12:50:51] <temporalfox> x++ is fine as long as the value is not used
+[12:50:57] <temporalfox> like a for loop
+[12:51:03] <temporalfox> so I need to figure this out
+[12:51:07] <temporalfox> and do more testing for codetrans
+[12:51:14] <purplefox> ok
+[12:51:55] <purplefox> vertx-examples:
+[12:51:59] <purplefox> we need more examples
+[12:52:05] <temporalfox> yes
+[12:52:11] <purplefox> more examples of the clients
+[12:52:14] <purplefox> and various other things
+[12:52:15] <temporalfox> simple data
+[12:52:18] <purplefox> and end to end stuff
+[12:52:33] <temporalfox> I think arnaud is porting vtoons
+[12:52:45] <purplefox> aesteve: ^
+[12:52:46] <aesteve> actually not porting vtoons
+[12:52:49] <aesteve> https://github.com/aesteve/vertx-feeds
+[12:53:07] <aesteve> it's more complicated, it involves redis / mongo and worker verticles
+[12:53:20] <temporalfox> it's end-to-end-to-end
+[12:54:03] <aesteve> i had trouble to find an example that's actually interesting and useful and doesn't involve alot of stuff
+[12:54:18] <aesteve> maybe it's not a good approach to have so many things into one single example
+[12:54:21] <aesteve> idk :\
+[12:55:14] <temporalfox> purplefox the build needs some work
+[12:55:16] <aesteve> this one is good 'cause you have an actual example of what you can use worker verticles for : reading RSS feeds periodically
+[12:55:58] <purplefox> aesteve: what does feedbroker do?
+[12:56:23] <aesteve> reads RSS feeds (or maybe other stuff if you have a good idea) periodically
+[12:56:40] <purplefox> why does it need to be a worker?
+[12:56:56] <aesteve> I wanted to use a blocking API (Rome) at first
+[12:57:28] <aesteve> but then I realized I didn't provide a vertx.createClient example
+[12:57:41] <aesteve> if I use Rome => it's a worker
+[12:58:03] <aesteve> if I want to provide an example of createClient and asynchronous stuff => it's no longer a worker
+[12:58:23] <aesteve> it's a matter of choice of what is the most important to showcase
+[12:59:13] <purplefox> i see you're also creating a non shared mongo client and passing it into the verticles...
+[12:59:19] <purplefox> that doesn't seem right to me
+[12:59:46] <purplefox> the point of the shared client stuff is so you don't have to do this
+[13:01:34] <purplefox> but generally looks good :)
+[13:01:54] <purplefox> i would still like to see a simple web example with, say, an angularjs front end though
+[13:02:03] <purplefox> like the vtoons
+[13:02:28] <purplefox> temporalfox: ok julien, i think we're done
+[13:02:44] <temporalfox> purplefox ok cool ^^
+[13:02:45] <purplefox> next thing is to split up who is doing what
+[13:02:51] <purplefox> we can do this after lunch
+[13:02:57] <temporalfox> ok perfect
+[13:03:03] <temporalfox> I'm starving :-)
+[13:05:16] <purplefox> AlexLehm: hi alex, do you have a few minutes to chat?
+[13:05:30] <aesteve> ok purplefox that's the first time I'm working with Mongo, I'm not expecting to do it right in the first shot :)
+[13:05:43] <AlexLehm> yes sure
+[13:05:46] <aesteve> I'll open an issue so that I don't forget about your advice
+[13:05:50] <purplefox> aesteve: so basically you don't need to pass in the mongo client instance
+[13:05:58] <purplefox> aesteve: just do createShared from wherever you need it
+[13:06:21] <purplefox> AlexLehm: great... so we were just discussing what remains to be done for V3
+[13:06:36] <purplefox> AlexLehm: one of the main outstanding areas is the mail client
+[13:07:07] <purplefox> did you have a chance to work on the fixes we discussed last week?
+[13:07:19] <AlexLehm> I started on the todo list on the weekend
+[13:07:55] <AlexLehm> i fixed the pool tests to actually assert something
+[13:08:09] <AlexLehm> i started the connection pool tests
+[13:08:23] <AlexLehm> sunday evening, i didn't get around to commiting that
+[13:08:27] <purplefox> cool, which branch are you working in?
+[13:08:51] <AlexLehm> i created a new wip branch, but I didn't push the changes last evening
+[13:09:05] <purplefox> ok np. can you just push it now?
+[13:09:06] <AlexLehm> i can do it this evening
+[13:09:20] <AlexLehm> ah, I'm at the office so I don't have access to my machine
+[13:09:33] <purplefox> alright, no problem
+[13:09:46] <AlexLehm> I could ask my gf to push the changes though (I know shes at home since shes using the computer)
+[13:10:04] <purplefox> we can wait until this evening. no problem
+[13:10:07] <AlexLehm> ok
+[13:12:23] <AlexLehm> i meant to ask you about the merge operation I did on Saturday, I'm not sure if I that wrong, but I think I merged the changes from the PR into a new branch and then checked that and merged it into master
+[13:12:50] <AlexLehm> or did you want the change to be merged into a new wip branch?
+[13:13:32] <purplefox> i was a bit confused about what was happening there
+[13:13:44] <purplefox> i expected that branch to be merged directly into master
+[13:13:48] <purplefox> but you created a new one, not sure why
+[13:13:51] <AlexLehm> ah ok
+[13:14:20] <purplefox> to be honest I don't really understand what you did, but the end result was it got into master
+[13:14:41] <AlexLehm> basically I did the following
+[13:14:59] <AlexLehm> close the pr with a comment to merge it with a new branch
+[13:15:20] <AlexLehm> create a branch wip based on the current master, merge the changes from the refactorings branch
+[13:15:29] <AlexLehm> revise that a small bit and merge it into master
+[13:15:47] <purplefox> why not just merge the refactorings straight into the wip?
+[13:15:57] <purplefox> then you wouldn't need a new branch
+[13:16:09] <purplefox> after all the PR was based against the wip branch anyway
+[13:16:26] <AlexLehm> the wip was the old one that was merged into master before by you, I don't think you can merge that agin
+[13:16:27] <AlexLehm> again
+[13:16:38] <AlexLehm> I may be wrong with that though
+[13:16:52] <purplefox> i thought you were working on WIP?
+[13:17:07] <purplefox> wip hadn't been merged into master
+[13:17:14] <AlexLehm> the old one yes
+[13:17:22] <purplefox> you have more than one branch called wip?
+[13:17:44] <AlexLehm> no, i have deleted the old wip branch after the merge and created a new one based on master
+[13:17:53] <AlexLehm> and then i merged that and delete the branch
+[13:17:55] <purplefox> right, so you were working on that branch
+[13:18:08] <purplefox> which is why i based the pr "refactorings" on wip
+[13:18:13] <purplefox> and not on master
+[13:18:21] <AlexLehm> but you merged it before I think
+[13:18:34] <purplefox> it doesn't matter
+[13:19:11] <AlexLehm> the changes you made in the refactorings branch are now in master, I hope that is ok
+[13:19:48] <purplefox> we got there in the end... but next time, after a review the best thing to do is is to add a note "finished review" or whatever
+[13:19:58] <purplefox> not just merge directly
+[13:20:09] <purplefox> this is what julien and i do all the time
+[13:21:16] <AlexLehm> ok, sorry that i got that wrong
+[13:21:32] <purplefox> yes so workflow is basically this:
+[13:21:45] <purplefox> 1. someone does some work and submits a PR
+[13:21:51] <purplefox> 2. other people get asked to review it
+[13:22:01] <purplefox> 3. when review is complete, the changes can be merged.
+[13:22:21] <purplefox> so in this case i asked you and julien to review it
+[13:22:57] <purplefox> so if you're happy just say "looks good to me" or something
+[13:24:20] <AlexLehm> ok
+[13:26:23] <purplefox> then once you said "ok"
+[13:26:33] <purplefox> i would then see if julien thinks its ok too.
+[13:26:50] <purplefox> then if he is ok, i would merge the refactorings branch into the wip branch
+[13:27:05] <purplefox> (by clicking the merge button on github)
+[13:27:15] <purplefox> then we just have your branch to merge
+[13:27:28] <purplefox> so then next thing, you'd submit a PR of your changes (wip) against master
+[13:27:42] <purplefox> and then you'd say "hey guys can you please review this?"
+[13:27:58] <purplefox> and then we'd review any further changes you'd done in your WIP branch
+[13:28:04] <purplefox> and if ok, you'd then merge that into master
+[13:28:12] <purplefox> that's basically how it's supposed to work ;)(
+[13:28:42] <AlexLehm> ok, i will do that in the future
+[13:34:15] <AlexLehm> ok, i will go online again in the evening
+[13:35:04] <purplefox> thanks alex
+[13:36:34] <aesteve> since I had some time during lunch : https://github.com/aesteve/vertx-feeds/commit/9a1a7d0b1568192ec87dc88e51f3c8b64ac4cb57
+[13:36:43] <aesteve> I guess that's what you had in mind purplefox ?
+[13:37:15] <AlexLehm> you discussed project names for apex before, if you consider Sherpa (which is kind of good I think), you could call it either Tenzing or Norgay, that was the Sherpa of Edmund Hillary on his first ascent of Mt. Everest
+[13:37:57] <AlexLehm> who was usually called Sherpa Tenzing
+[13:38:46] <aesteve> I quite like sherpa actually, but not sure it's good as a project name (collision with a common name ?) idk
+[13:39:08] <aesteve> but the idea behind the name it is cool
+[14:44:37] <saltuk> hi  can some1  help me  logic of something like  http://codepaste.net/si872f
+[15:09:32] <D-Spair> saltuk:  Wrong Vertex... This channel is about the Vert.x tool-kit.
+[15:10:06] <D-Spair> saltuk:  NVM, I see what's happening there.
+[15:10:49] <purplefox> temporal_: hi julien, one thing we forgot to discuss is metrics
+[15:10:54] <D-Spair> saltuk:  First off, you want your class to extend "AbstractVerticle" so that all of the Vert.x setup  is done for you..
+[15:10:58] <temporal_> purplefox indeed
+[15:11:56] <purplefox> one sec, my irc client is screwing up. going to reboot it....
+[15:14:44] <purplefox> temporal_: ok back now
+[15:14:52] <purplefox> temporal_: we didn't discuss metrics
+[15:15:33] <purplefox> temporal_: is there anything outstanding on that?
+[15:15:40] <temporal_> purplefox not for the moment
+[15:15:59] <temporal_> purplefox I believe it would need a proper reimplementation for an spi consumer
+[15:16:10] <temporal_> purplefox and more thought
+[15:16:23] <temporal_> and I think we said that we will provide something more appropriate later
+[15:16:45] <temporal_> concerning the SPI, I think it's quite ok now beside the thread checks
+[15:16:57] <purplefox> can you elaborate on that a bit? "proper reimplementation for an spi consumer"
+[15:17:15] <temporal_> codahale is for local in VM implementation
+[15:17:30] <temporal_> Thomas Segismont is contributing an hawkular implementation
+[15:17:55] <temporal_> with codahale
+[15:18:01] <temporal_> metrics are not persisted
+[15:18:10] <temporal_> and on a cluster you cannot get a global view of the system
+[15:18:34] <temporal_> I started to work a bit on an HdrHistogram implementation
+[15:18:51] <temporal_> that would scale better than codahale
+[15:18:59] <purplefox> ok but this is just a different implementation, no>
+[15:19:01] <temporal_> yes
+[15:19:10] <temporal_> so with the curent implementation I think we are good
+[15:19:26] <temporal_> and we need to revisit / improve that after 3.0
+[15:19:31] <purplefox> ok
+[15:19:51] <temporal_> concerning the SPI itself, I think it can be improved in some part
+[15:19:57] <temporal_> mainly the deployment callback
+[15:20:04] <temporal_> lifecycle of deployed verticles
+[15:20:12] <temporal_> to provide more info about what is deployed
+[15:20:26] <temporal_> and perhaps the verticle deployment hierarchy
+[15:20:32] <D-Spair> saltuk:  Why do you want to create a new context to run on?
+[15:20:53] <temporal_> so bottom line beside what I mentionned for the threads, I think we are good for now
+[15:20:56] <D-Spair> saltuk:  Is there some operation requirement for that? You need a separate context to make something work?
+[15:21:11] <temporal_> purplefox one area we need to spend time is the build
+[15:21:41] <temporal_> purplefox have doc generation play better with multimodule project
+[15:22:24] <temporal_> purplefox some modules cannot execute tests if the module is not the cwd
+[15:27:11] <D-Spair> saltuk:  Have a look at: http://codepaste.net/innfms
+[15:39:20] <D-Spair> purplefox: temporal_: I Assume that something like a DatabaseManager object for OrientDB would be "difficult" to add to the clustered context, right?
+[15:39:50] <D-Spair> Since it is connection oriented, it would have to be instantiated separately on each node of a cluster, right?
+[15:56:39] <saltuk> D-Spair, thanx for the info . ;)
+[20:08:57] <jtruelove> apex question, where do I supply a no route found error handler globally? I don't see that interface on the Router object itself. The docs seem to indicate that it's possible. I don't see it on the HttpServer object either. I want to emulate the old 'noMatch' functionality. I see you can supply one on one off Route objects but that seems like it would only
+[20:08:57] <jtruelove> apply to that Route vs anything coming in that didn't anything at all.
+[20:18:33] <jtruelove> purplefox: ^
+[20:20:39] <purplefox> jtruelove: you should just be able to supply a failureHandler that matches all routes:
+[20:20:46] <purplefox> router.route().failureHandler(myHandler);
+[20:20:55] <jtruelove> heh yeah just found that
+[20:21:47] <jtruelove> thanks, what happens if you call route() multiple times? I'm guessing nothing
+[20:22:33] <purplefox> you can create as many routes as you want, any matching ones will be called in the order you created them
+[20:23:14] <jtruelove> right but if you call route() multiple times on the same Router it would all map to the same thing right?
+[20:23:25] <jtruelove> unless you modified after you created it of coruse
+[20:23:32] <purplefox> not sure what you mean
+[20:23:49] <purplefox> when a request comes in
+[20:23:57] <jtruelove> you call router.route() multiple times on the same Router object
+[20:24:27] <purplefox> yes, you can call router.route() multiple times, most apps will do this
+[20:24:28] <jtruelove> you'd end up with multiple routes at that point all matching everything
+[20:24:37] <purplefox> yes, that's fine
+[20:25:27] <purplefox> when a request comes in, apex finds the first matching route out of all the routes
+[20:25:36] <purplefox> then it calls the handler for that
+[20:25:54] <purplefox> and then, if you call context.next() in your handler, then it calls the next matching route (if any)
+[20:25:56] <purplefox> etc
+[20:26:05] <jtruelove> right
+[20:26:09] <purplefox> so you can have as many matching routes as you want. and it's pretty common to have many
+[20:26:41] <jtruelove> yeah i can see that, was just thinking about the match 'all' route
+[20:28:25] <purplefox> another way of doing it, is to do a router.route() and set a normal handler, not a failureHandler
+[20:28:43] <purplefox> but you'll need to add this as the *last* route, or it will be called for every request
+[20:29:35] <purplefox> jtruelove: ok sorry jeremy i have to shoot off now. but any more issues I'll be around tomorrow :)
+[20:29:36] <purplefox> cheers
+[21:16:53] <jtruelove> np, I got what I need :D
+[21:47:26] <jtruelove> is there a standard way that fatjars are done in gradle with vertx3?
+[23:11:30] <AlexLehm> temporal_, can async object only be completed once? I had two complete calls on the same object due to a cut'n'paste mistake. maybe it would be good to give a warning about that
+[23:11:50] <temporal_> I believe they can be completed once but I need to check
+[23:12:14] <temporal_> I agree a warn would allow to detect bad practice
+[23:26:03] <AlexLehm> i can write an issue if you like
+[23:59:27] <Ephemeral> stahp making copy pasta :(