Differences

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

Link to this comparison view

irc:1436911200 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[01:07:41] <​DP2015>​ whats the differnece between ​  ​vertx-mysql-postgresql-client, ​    SQL common ​ and   JDBC client
 +
 +[08:16:39] <​jac_>​ The JDBC examples at https://​github.com/​vert-x3/​vertx-examples/​tree/​master/​jdbc-examples all lead to broken links.
 +
 +[08:22:36] <​millrossjez>​ they seem to work for me
 +
 +[08:23:19] <​millrossjez>​ eg I just navigated from the url you gave to https://​github.com/​vert-x3/​vertx-examples/​blob/​master/​jdbc-examples/​src/​main/​groovy/​io/​vertx/​example/​jdbc/​query_params/​jdbc_example.groovy
 +
 +[08:29:14] <​jac_>​ Yes, the source is there only the links lower on the page lead to 404's for me.
 +
 +[08:43:50] <​purplefox_>​ jac_: please could you add a github issue?
 +
 +[08:43:56] <​purplefox_>​ i trust you can navigate manually for now
 +
 +[09:18:20] <​jac_>​ purplefox - sure thing, I'll make sure it's done sometime today.
 +
 +[10:11:42] <​purplefox_>​ temporalfox:​ cescoffier: cescoffier: hi folks did you get a chance to look at https://​github.com/​vert-x3/​wiki/​wiki/​Vert.x-3-Official-stack-and-component-maintainers yet?
 +
 +[10:11:56] <​temporalfox>​ wasn't aware of it :-)
 +
 +[10:12:07] <​purplefox_>​ i posted on the google group yesterday about it
 +
 +[10:12:23] <​temporalfox>​ I'm genboy !!!!
 +
 +[10:12:32] <​temporalfox>​ catching up :-)
 +
 +[10:13:50] <​purplefox_>​ i've put down some initial assignments but these are just guesses
 +
 +[10:14:08] <​purplefox_>​ yeah, genboy, but this is just because you've done most of the work in that area :)
 +
 +[10:14:50] <​purplefox_>​ temporalfox:​ pmlopes cescoffier: also some feedback/​discussion on the actual document would be good
 +
 +[10:14:55] <​temporalfox>​ ok
 +
 +[10:15:05] <​purplefox_>​ do you agree? disagree? (with the idea)
 +
 +[10:15:15] <​purplefox_>​ can it be improved etc
 +
 +[10:16:40] <​temporalfox>​ at first look it makes sense to me
 +
 +[10:19:04] <​purplefox_>​ so it's really just formalising what is already true - the independent nature of Vert.x
 +
 +[10:19:22] <​cescoffier>​ I'm the hype guy : just the hype thingy for me :-)
 +
 +[10:19:22] <​cescoffier>​ I definitely agree, we need referals for all components (point of contact)
 +
 +[10:20:36] <​purplefox_>​ +1
 +
 +[10:20:46] <​purplefox_>​ I'd also like to actively try and get more non red hat people involved
 +
 +[10:21:02] <​purplefox_>​ as we are quite "​skewed"​ towards RH at the moment
 +
 +[10:21:28] <​pmlopes>​ i agree
 +
 +[10:24:00] <​purplefox_>​ if you guys have a preference for any particular component (or don't want to do one) just say
 +
 +[10:24:12] <​purplefox_>​ like i say, what i have put down there for now is just an initial guess
 +
 +[10:24:16] <​purplefox_>​ there are plenty of slots to fill
 +
 +[10:24:51] <​pmlopes>​ i was thinking that i can take care of sql and/or auth
 +
 +[10:26:05] <​purplefox_>​ sounds good to me
 +
 +[10:26:17] <​purplefox_>​ that goes together well with web stuff too
 +
 +[10:26:45] <​pmlopes>​ yes
 +
 +[10:28:39] <​purplefox_>​ but also we need to leave some stuff for clement too :)
 +
 +[10:28:47] <​purplefox_>​ cescoffier: do you have any preferences?​
 +
 +[10:28:57] <​pmlopes>​ only hip stuff, mongodb :)
 +
 +[10:29:06] <​pmlopes>​ just kidding :)
 +
 +[10:29:27] <​cescoffier>​ the services
 +
 +[10:29:28] <​cescoffier>​ I already looked into them
 +
 +[10:29:37] <​cescoffier>​ (mongo is not hype anymore ;-))
 +
 +[10:30:22] <​cescoffier>​ having the same lead for data access make sense as things need to be homogeneous
 +
 +[10:32:28] <​cescoffier>​ there are '​transversal'​ stuff that could be mentioned too
 +
 +[10:33:28] <​cescoffier>​ such as build, examples ....
 +
 +[10:33:55] <​purplefox_>​ +1
 +
 +[10:34:05] <​purplefox_>​ actually i just added examples and added you as maintainer ;)
 +
 +[10:34:27] <​purplefox_>​ build stuff, you mean as in managing the vertx-parent,​ vertx-ext-parent stuff?
 +
 +[10:34:50] <​cescoffier>​ yes, + CI and automatisation
 +
 +[10:35:07] <​cescoffier>​ and stack
 +
 +[10:35:08] <​purplefox_>​ i think CI should be the responsibility of the individual component maointainer to make sure the component is on CI
 +
 +[10:35:29] <​purplefox_>​ stack i have on the list already under "​distributions"​
 +
 +[10:35:54] <​cescoffier>​ Missed it sorry
 +
 +[10:36:08] <​purplefox_>​ i've assigned julien but if you want it...
 +
 +[10:36:58] <​purplefox_>​ up til now Julien has been our in house "Maven guru", but maybe you want to take over the role, considering you have a lot of skills in this area :)
 +
 +[10:38:48] <​cescoffier>​ Up to you, I can do it.
 +
 +[10:40:09] <​purplefox_>​ don't feel compelled to say yes, it's totally up to you. i can leave it with julien too :)
 +
 +[10:40:21] <​purplefox_>​ maybe you have a fight amongst yourselves ;)
 +
 +[10:41:29] <​cescoffier>​ no no, Maven is fine
 +
 +[10:41:39] <​cescoffier>​ I will do it
 +
 +[10:42:05] <​cescoffier>​ except if Julien want to keep it ;-)
 +
 +[10:42:12] <​temporalfox>​ I think we can share it :-)
 +
 +[10:42:42] <​purplefox_>​ ok so let's just keep julien as maintainer for now, but you can help out if you like
 +
 +[10:42:55] <​cescoffier>​ ok
 +
 +[10:43:06] <​purplefox_>​ one key thing about maintainership is you don't have to do all the work yourself, delegation is fine. it's just the responsibility for delivery is on the maintainer
 +
 +[10:44:10] <​temporalfox>​ I would rather for now keep "​maintainership"​ and hand it to clement over time, as he seems more active than me on the subject
 +
 +[10:44:19] <​purplefox_>​ cescoffier: I'm not sure if michael will be able to take maintainership of the website, but if not maybe that's something you would like too?
 +
 +[10:44:29] <​purplefox_>​ considering you know it pretty well now, after your work with blogs etc
 +
 +[10:44:41] <​cescoffier>​ definitely, I'm now able to maintain the web site
 +
 +[10:44:43] <​purplefox_>​ temporalfox:​ +1
 +
 +[10:46:43] <​cescoffier>​ right now, I'm more looking at things on almost any project than focusing a one
 +
 +[10:47:32] <​purplefox_>​ right and it's fine to continue doing that
 +
 +[10:47:53] <​purplefox_>​ i think we should continue to fix bugs / do stuff in other projects
 +
 +[10:48:18] <​purplefox_>​ this is really more about ownership which is less of an issue for us as full time employees but more important when it comes to community maintainers
 +
 +[10:48:46] <​purplefox_>​ so don't feel that just because you're not maintainer you can't do stuff in a component :)
 +
 +[10:49:06] <​cescoffier>​ So I can still break things everywhere :-)
 +
 +[10:49:56] <​purplefox_>​ yes :)
 +
 +[10:49:59] <​purplefox_>​ (me too)_
 +
 +[10:51:01] <​cescoffier>​ and ownerships is going to evolve with time
 +
 +[10:51:17] <​cescoffier>​ as new components are going to appear and work load too
 +
 +[10:52:18] <​purplefox_>​ another related thing we should discuss is assignment of 3.1 tasks
 +
 +[10:52:55] <​pmlopes>​ yes when should we do that?
 +
 +[10:52:59] <​cescoffier>​ Was thinking doing that on Friday during the meeting
 +
 +[10:53:35] <​cescoffier>​ we could add a column in the spreadsheet and say what we would like to do
 +
 +[10:54:41] <​purplefox_>​ some of the stuff is pretty obvious - like Ceylon - julien ;)
 +
 +[10:54:49] <​purplefox_>​ other stuff is not us
 +
 +[10:54:51] <​cescoffier>​ I would like to do the Starter class
 +
 +[10:55:16] <​purplefox_>​ sounds good to me
 +
 +[10:55:33] <​purplefox_>​ let me just add names by the obvious stuff for now...
 +
 +[10:56:27] <​temporalfox>​ I've been sharing my time between ceylon and shell recently
 +
 +[10:56:56] <​purplefox_>​ ok i've added some names, could you take a look?
 +
 +[10:57:57] <​cescoffier>​ where ?
 +
 +[10:58:06] <​purplefox_>​ https://​github.com/​vert-x3/​wiki/​wiki/​Vert.x-Roadmap
 +
 +[10:58:08] <​purplefox_>​ scroll down
 +
 +[10:58:31] <​purplefox_>​ redeploy is up for grabs
 +
 +[10:58:55] <​cescoffier>​ the redeploy is part of the starter class refactoring
 +
 +[10:58:57] <​temporalfox>​ I believe clement would be fine with it :-)
 +
 +[10:59:02] <​purplefox_>​ ok fine
 +
 +[10:59:23] <​purplefox_>​ dns based discovery
 +
 +[10:59:24] <​temporalfox>​ I would mind working on event bus transport plugable at some point
 +
 +[10:59:30] <​cescoffier>​ I will also do the DNS based discovery as it's mainly for docker / openshift
 +
 +[10:59:52] <​purplefox_>​ ha, i just grabbed the event bus one.. but maybe we can work together on it :)
 +
 +[10:59:59] <​temporalfox>​ but maybe purplefox_ ​ you prefer to do it :-)
 +
 +[11:00:09] <​temporalfox>​ purplefox_ no problem
 +
 +[11:00:17] <​temporalfox>​ I spent some time on event bus internal and bug fixes
 +
 +[11:00:22] <​temporalfox>​ I just feel familiar with it
 +
 +[11:00:29] <​purplefox_>​ my slight concern with you julien is we only have you partially, and ceylon is you're "​official"​ focus ;)
 +
 +[11:00:30] <​temporalfox>​ we'll do like the worker
 +
 +[11:00:31] <​pmlopes>​ i can try to look at the tcp socket bridge
 +
 +[11:00:39] <​temporalfox>​ you do the impl and I find the bugs :-)
 +
 +[11:00:42] <​purplefox_>​ lol
 +
 +[11:00:58] <​purplefox_>​ so i write the bugs, then you make it usable? seems like a fair deal ;)
 +
 +[11:00:58] <​temporalfox>​ yes you are right
 +
 +[11:01:13] <​temporalfox>​ given that I also want to do some metrics SPI improvements for shell
 +
 +[11:01:22] <​temporalfox>​ to expose more internals interactively
 +
 +[11:01:24] <​cescoffier>​ they are tasks not listed here around the eventbus.js (Node.JS compatibility,​ API update)
 +
 +[11:01:51] <​temporalfox>​ one non official task I would actually claim
 +
 +[11:01:57] <​temporalfox>​ (like eventbus that clement said)
 +
 +[11:02:09] <​temporalfox>​ is codegen usability / improvements
 +
 +[11:02:19] <​purplefox_>​ right, so the roadmap list is just the larger high level tasks
 +
 +[11:02:19] <​temporalfox>​ to have other use it
 +
 +[11:02:24] <​temporalfox>​ but it's implicit
 +
 +[11:02:26] <​purplefox_>​ there are a bunch of other smaller tasks and fixes to do
 +
 +[11:02:33] <​purplefox_>​ maybe we should capture *everything* as issues?
 +
 +[11:03:27] <​cescoffier>​ yes, we should
 +
 +[11:03:45] <​cescoffier>​ I was even thinking opening mirror issues on vertx-3/​issues for issues on BZ
 +
 +[11:03:54] <​cescoffier>​ just to visualize them in waffle
 +
 +[11:04:01] <​temporalfox>​ I think we should capture ideas but not go in the trap to have too many fine grained issues
 +
 +[11:04:02] <​pmlopes>​ yes i agree otherwise we loose track
 +
 +[11:05:23] <​cescoffier>​ Most of these tasks are going to be umbrellas anyway
 +
 +[11:06:25] <​purplefox_>​ sounds reasonable
 +
 +[11:06:36] <​purplefox_>​ i think we should also consider using milestone tags in GH issues
 +
 +[11:06:38] <​cescoffier>​ So we should create the high level task and each implementor can refer to these issues when doing some work
 +
 +[11:06:42] <​purplefox_>​ so we can say which release they are due on
 +
 +[11:07:01] <​purplefox_>​ cescoffier: +1
 +
 +[11:07:34] <​purplefox_>​ and then we also go through all other issues and tag them with milestone 3.1 if they are going in 3.1 (?)
 +
 +[11:07:54] <​cescoffier>​ ok
 +
 +[11:08:06] <​cescoffier>​ I can create the issues if you want
 +
 +[11:08:52] <​purplefox_>​ sounds good
 +
 +[11:08:53] <​purplefox_>​ thanks
 +
 +[11:09:15] <​purplefox_>​ bugzilla is still a pain, of course. I hate having to also manage issues there :(
 +
 +[11:09:27] <​cescoffier>​ will do that today (once I finish the vertx-web exampels automation)
 +
 +[11:09:35] <​purplefox_>​ hmm, i wonder if we can mirror bz core issues
 +
 +[11:10:04] <​purplefox_>​ i.e. every time we enter a BZ for vertx-core (as eclipse mandates) we can also open a corresponding issue in vertx-core github issues
 +
 +[11:10:11] <​purplefox_>​ then we can see everything nicely in waffle
 +
 +[11:10:12] <​cescoffier>​ I can have a look, I've seen a web site doing the mirroring
 +
 +[11:10:29] <​purplefox_>​ ah if it's automatic even better :)
 +
 +[11:10:40] <​purplefox_>​ that would be a killer
 +
 +[11:12:37] <​cescoffier>​ I let you know today
 +
 +[11:22:06] <​purplefox_>​ temporalfox:​ could you ask thomas segismont if he is happy to be the official maintainer for the hawkular metrics, and point him in the direction of https://​github.com/​vert-x3/​wiki/​wiki/​Vert.x-3-Official-stack-and-component-maintainers so he knows the expectations and responsibilities?​
 +
 +[11:22:22] <​temporalfox>​ yes I will ask him
 +
 +[11:22:31] <​purplefox_>​ thanks
 +
 +[11:22:43] <​temporalfox>​ he's maybe on holidays now so don't expect an quick answer :-)
 +
 +[11:26:00] <​cescoffier>​ pmlopes: are you around ?
 +
 +[11:28:05] <​cescoffier>​ purplefox_ did you have time to have a quick look to the introduction to Vert.x post series ?
 +
 +[11:32:38] <​pmlopes>​ yes i am
 +
 +[11:32:58] <​cescoffier>​ pmlopes: in the realtime angular js example, we have quite some JS libraries
 +
 +[11:33:13] <​cescoffier>​ in the js3rdparty directory
 +
 +[11:33:23] <​cescoffier>​ other examples don't have this and use CDN
 +
 +[11:33:32] <​cescoffier>​ is it on purpose ?
 +
 +[11:33:34] <​pmlopes>​ no
 +
 +[11:34:12] <​pmlopes>​ i think it can be refactored to use only CDNs
 +
 +[11:37:27] <​cescoffier>​ ok, so I don't have to test that files are served ;-)
 +
 +[11:38:11] <​cescoffier>​ I just have cors to do and I cover all web examples
 +
 +[11:41:52] <​purplefox_>​ pmlopes: cescoffier: temporalfox:​ i think we should also consider having a periodic "​vert.x committer"​ Bluejeans (?) meeting every so often, to discuss roadmap with the other vert.x committers who aren't all going to be Red Hat folks
 +
 +[11:42:09] <​purplefox_>​ i.e. it wouldn'​t be an internal meeting
 +
 +[11:42:16] <​temporalfox>​ some open source projects do that with google hangouts
 +
 +[11:42:26] <​temporalfox>​ I remember I did a couple with jenkins team
 +
 +[11:42:28] <​purplefox_>​ +1
 +
 +[11:42:31] <​temporalfox>​ just to see how it was
 +
 +[11:42:44] <​pmlopes>​ in that case shouldn'​t we use google hanghouts? or can anyone join bluejeans
 +
 +[11:42:48] <​purplefox_>​ i'm thinking maybe we could do that once per month
 +
 +[11:42:58] <​cescoffier>​ yes, that would be good to do them periodically
 +
 +[11:43:17] <​cescoffier>​ anyone can join bluejean if they have an invitation BUT people prefer hangout
 +
 +[11:43:37] <​purplefox_>​ both bj and google hangouts has pros and cons:
 +
 +[11:43:43] <​purplefox_>​ bluejeans: doesn'​t work on chrome on linux
 +
 +[11:43:55] <​purplefox_>​ google hangouts: requires google+ account
 +
 +[11:44:24] <​purplefox_>​ from a technical point of view i prefer google hangouts
 +
 +[12:02:10] <​purplefox_>​ pmlopes: would you like to be the maintainer for the JS Vert.x language implementation?​
 +
 +[12:02:44] <​pmlopes>​ humm yes, i need to get acquainted with the code though
 +
 +[12:03:22] <​purplefox_>​ maybe this would be good for you as it would get you aquainted with the codegen stuff
 +
 +[12:03:55] <​purplefox_>​ temporalfox:​ And you julien the groovy lang impl too i guess, unless you can think of anyone else?
 +
 +[12:05:47] <​aesteve>​ hi everyone :)
 +
 +[12:06:02] <​purplefox_>​ hi
 +
 +[12:06:18] <​aesteve>​ pmlopes: since you're the vertx-web guru maintainer, maybe you could tell me if https://​github.com/​vert-x3/​vertx-web/​pull/​130 is OK ?
 +
 +[12:10:08] <​pmlopes>​ why does the renderTemplate needs to be run inside executeBlocking?​ template is already in memory i guess so theoretically no blocking operations should happen right?
 +
 +[12:11:25] <​purplefox_>​ pmlopes: i think it's because it just might take a long time, if the template / data is big
 +
 +[12:11:32] <​purplefox_>​ but i think the executeBlocking should be configurable
 +
 +[12:11:42] <​purplefox_>​ because in many cases it will be very quick
 +
 +[12:12:15] <​aesteve>​ yes I was concerned about rendering in case Context.Data() contains a lot of stuff, or the template loops on something huge
 +
 +[12:12:38] <​aesteve>​ more than configurable,​ adaptative would be awesome
 +
 +[12:12:57] <​purplefox_>​ I would default _not_ use executeBlocking but allow it as an option for those user where rendering is slow
 +
 +[12:13:10] <​purplefox_>​ adaptable would be great, but it's also hard to get it right
 +
 +[12:13:26] <​cescoffier>​ purplefox_ temporalfox pmlopes : All web examples have been automated.... Results soon.
 +
 +[12:13:35] <​pmlopes>​ cool!
 +
 +[12:13:54] <​aesteve>​ not sure if I dreamed it but didn't you tell someone on the user group that for template rendering you used some kind of adaptative blocking/​non-blocking ?
 +
 +[12:15:46] <​purplefox_>​ that's in statichandler
 +
 +[12:15:57] <​purplefox_>​ but we should really make it general
 +
 +[12:17:04] <​aesteve>​ Anyway, how would you make it configurable ? Because it's rmore a template/​template,​ or even worse, context/​context
 +
 +[12:17:58] <​aesteve>​ eg : a template loops on context.data and does heavy stuff
 +
 +[12:18:24] <​aesteve>​ and obviously, context.data() is fetched from database...
 +
 +[12:18:48] <​aesteve>​ in this case, there'​s no way the user can tell if it's gonna be slow when creating the template engine
 +
 +[12:21:53] <​aesteve>​ the only thing I'd see is like a "​criteria API" like "​boolean isBlocking(String templateFileName,​ RoutingContext context)"​ returning false by default, and the user would derive GroovyTemplateEngine if needed ?
 +
 +[12:21:58] <​aesteve>​ but that seems overkill
 +
 +[12:23:27] <​purplefox_>​ aesteve: just a boolean flag when creating the template engine i was thinking
 +
 +[12:23:37] <​purplefox_>​ or even in the template handler
 +
 +[12:24:30] <​aesteve>​ yeah maybe. I'm not sure that suits the use case well
 +
 +[12:25:02] <​aesteve>​ a templateHandler will potentially handle a lot of templates, most of them are simple but a single one is "​dangerous"​
 +
 +[12:25:40] <​aesteve>​ well I'm not sure but I'll do that. "When in doubt, go for the easy implementation"​.
 +
 +[12:30:41] <​purplefox_>​ indeed. we can always do more sophisticated implementations later. and at least this allows a user to separate out their slow templates from their fast ones and use different template handlers if there is an issue
 +
 +[12:32:16] <​purplefox_>​ aesteve: hmm just a thought...
 +
 +[12:32:46] <​purplefox_>​ users can already make any template handler blocking by just setting it as blocking handler no?
 +
 +[12:32:48] <​purplefox_>​ route().blockingHandler(TemplateHandler.create(..));​
 +
 +[12:33:02] <​purplefox_>​ so i guess a boolean flag is redundant
 +
 +[12:34:47] <​aesteve>​ indeed
 +
 +[12:35:03] <​aesteve>​ i thought I had written it
 +
 +[12:35:12] <​aesteve>​ I thought it out loud... maybe
 +
 +[12:36:17] <​aesteve>​ so, no boolean flag, no execute blocking on rendering, and let's keep in mind we could reuse the adaptative static handler in such situations
 +
 +[12:36:26] <​aesteve>​ are you fine with that ?
 +
 +[12:36:58] <​purplefox_>​ agreed
 +
 +[12:37:23] <​purplefox_>​ at some point in the future we should considering making blockingHandler more smart - i.e. adaptive
 +
 +[12:37:34] <​aesteve>​ ok I write it down in the PR and I'll fix it
 +
 +[12:38:21] <​purplefox_>​ but in any case, paulo is the maintainer here, this is just my suggestion :)
 +
 +[12:39:33] <​aesteve>​ I've added a note in the PR, and I'll see what Paole thinks after lunch
 +
 +[12:39:42] <​aesteve>​ Bon app[unknown:​eacute]tit,​ and thanks
 +
 +[12:42:11] <​purplefox_>​ cescoffier: can this one be closed now? https://​github.com/​vert-x3/​vertx-web/​issues/​137
 +
 +[12:50:10] <​purplefox_>​ temporalfox:​ cescoffier pmlopes: i'm thinking we should have another google group for vertx-committers
 +
 +[12:50:16] <​purplefox_>​ which only vertx-committers can post to
 +
 +[12:50:41] <​purplefox_>​ where we can discuss voting in new committers, new components etc, or roadmap discussions relating to the official stack
 +
 +[13:05:00] <​cescoffier>​ purplefox_: temporalfox wanted to look at the maven / npm stuff
 +
 +[13:05:10] <​cescoffier>​ that's why its not merged yet
 +
 +[13:05:46] <​purplefox_>​ ok, np
 +
 +[23:51:32] <​jtruelove>​ this code looks funny https://​github.com/​vert-x3/​vertx-web/​blob/​master/​src/​main/​java/​io/​vertx/​ext/​web/​impl/​RouteImpl.java#​L132
 +
 +[23:51:48] <​jtruelove>​ why does last take this parameter it totally ignores
 +
 +[23:52:18] <​jtruelove>​ true or false it's going last it seems