Differences

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

Link to this comparison view

— irc:1431295200 [2017/05/27 13:44] (current)
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 :(