This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[03:36:27] <saltuk> hi there .. i didnt know about vertx.getOrCreateContext() before see it on jdbc-client so this logic on 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>

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

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

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

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

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

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

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

[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

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

[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 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 :(