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

[09:36:57] *** ChanServ sets mode: +o purplefox

[09:53:31] <davsclaus> where is the vertx-eventbus.js file located

[09:53:42] <davsclaus> if i need to get hold of that, is it in some JAR somewhere ?

[09:56:17] <davsclaus> its mentioned here

[09:56:18] <davsclaus> https://github.com/vert-x3/vertx-web/blob/master/vertx-web/src/main/asciidoc/js/index.adoc#sockjs-event-bus-bridge

[09:56:27] <davsclaus> but there is no tell where its located and how you find it

[09:57:00] <tsegismont> pmlopes, ^^

[09:58:34] <pmlopes> @davclaus it is on a jar vertx-web as well as on npm https://www.npmjs.com/package/vertx3-eventbus-client

[09:58:56] <davsclaus> pmlopes i cannot find it in side vertx-web 3.3.3 release

[09:59:46] <davsclaus> its here in git

[09:59:46] <davsclaus> https://github.com/vert-x3/vertx-web/blob/master/vertx-web/src/client/vertx-eventbus.js

[09:59:49] <davsclaus> but not in the JAR

[09:59:57] <davsclaus> or i cannot find it in the JAR

[10:00:59] <davsclaus> ah darn its not in the JAR

[10:01:10] <davsclaus> its in a werx-web client.js file

[10:01:20] <davsclaus> would have hoped a mvn dependency was enough

[10:01:34] <davsclaus> its only 2 js files maybe put them in the JAR also

[10:01:57] <davsclaus> so people can easily use mvn to get hold of them and a maven plugin building a fat jar can auto include those files

[10:02:00] <pmlopes> if you need jars you can always get them from webjars.org

[10:02:25] <pmlopes> https://paste.gnome.org/p4okoyotl

[10:03:30] <davsclaus> its about easy of use and consisteny

[10:03:45] <davsclaus> make it darn easy for java developers to use vertx for a little html5 reactive web app

[10:05:47] <davsclaus> [ERROR] Failed to execute goal on project chapter7-vertx: Could not resolve dependencies for project com.camelinaction:chapter7-vertx:jar:2.0.0: Failed to collect dependencies at org.webjars.npm:vertx3-eventbus-client:jar:3.3.3 → org.webjars.npm:sockjs-client:jar:1.0.3 → org.webjars.npm:faye-websocket:jar:[0.7.3,0.8): No versions available for org.webjars.npm:faye-websocket:jar:[0.7.3,0.8) within specified range → [Help 1]

[10:05:59] <davsclaus> its not so easy when webjars dont work

[10:07:54] <davsclaus> https://github.com/fabric8io/vertx-maven-plugin/issues/21

[10:08:46] <cescoffier> hi @davsclaus

[10:09:03] <davsclaus> howdy cescoffier

[10:09:15] <cescoffier> looking at your issue, and I agree

[10:09:48] <davsclaus> btw many good examples at https://github.com/vert-x3/vertx-examples

[10:09:59] <davsclaus> however a bit poor for new users to use as baseline for new stuff

[10:10:03] <davsclaus> as its one giant project

[10:10:19] <davsclaus> easy of use and get started with vert.x would be good to have focus on

[10:10:26] <cescoffier> I definitely agree about our examples

[10:10:35] <cescoffier> we aim to restructure them completely

[10:10:35] <davsclaus> that is too overwhealming

[10:11:01] <cescoffier> probably using a specific org

[10:11:14] <cescoffier> our examples are also used as “integration tests”

[10:11:22] <davsclaus> ah yeah good idea

[10:11:27] <davsclaus> they touch a lot of functionality

[10:11:28] <cescoffier> in the sense we run them automatically and check the output / behavior

[10:12:37] <pmlopes> @davclaus if you look at webjars.org page you see that there are 2 gav's if you use the first one it does work

[10:12:43] <pmlopes> https://paste.gnome.org/pzymakj3y

[10:13:32] <davsclaus> i dont want to use webjars from a 3rd party

[10:13:37] <davsclaus> it should be io.vertx

[10:13:42] <davsclaus> and easier for new users

[10:13:53] <davsclaus> to get 2 .js files is hard

[10:14:19] <davsclaus> having to hunt them down in a git repo or copy from some existing example is not reassuring

[10:14:27] <davsclaus> you want the 3.3.3 version

[10:14:31] <davsclaus> or what version you use

[10:14:49] * davsclaus sorry for speaking with bad words

[10:21:18] <Rauno> could anyone explain how to trigger a line like this: “router.get(”/feed“).handler(this::handleGetFeedRequest);” in test? I get to that specific line just fine but can't seem to find a way to handleGetFeedRequest

[10:21:19] <pmlopes> web developers do prefer npm as their dependency repository, you don't see angujar/react/etc apps fetching client side js code from maven central, the “de-facto” standard is npm that is why vertx publishes the client there

[10:22:11] <pmlopes> there are bridges for users focusing only the java ecosystem, either use webjars or a npm maven plugin

[10:22:49] <pmlopes> if webjars is not trustworthy enough then I'd say use a npm maven plugin since the components on npm are released by the vertx project

[10:27:10] <davsclaus> yeah sure - but i am maybe talking about java developers doing smaller web apps in java only and want to use vert.x for that

[10:27:32] <davsclaus> its almost there, just a little more - easy to get started

[10:27:45] <davsclaus> ie the fat jar problem

[10:28:02] <davsclaus> and down the road confuguration, which i think cescoffier works on

[10:29:26] <cescoffier> I believe that the vertx maven plugin could implement some opiniatated ways (configurable of course)

[10:31:03] <davsclaus> yeah another project is killing the world doing that

[10:31:46] <davsclaus> just imagine that you can git clone an example, run a maven archetype, start.vertx.io website, and generate a small starter project

[10:31:56] <davsclaus> with vertx and web (if you [x] in web)

[10:32:23] <davsclaus> and then start hacking in a html page or something and add a few lines of java code to stream to the event bus

[10:32:45] <davsclaus> anything to get people running in 5 min

[10:32:50] <davsclaus> would be awesome

[11:12:33] <temporal_> ppatiern hi

[11:12:45] <ppatiern> temporal_: hi !

[11:12:54] <temporal_> I pushed the code in the repo

[11:13:08] <temporal_> I added todo in README

[11:13:42] <temporal_> I'm going to add polyglot generation I think

[11:13:46] <temporal_> now it does not gen anything

[11:15:45] <ppatiern> cool ! I'll jump into it asap !

[11:16:34] <temporal_> I'm going also to add an RxJava test

[11:16:39] <temporal_> to see how ti goes with Rxjava API

[11:16:43] <temporal_> because it is important

[11:18:20] <ppatiern> I'm curious to see the code because when I developed the AMQP - Kafka bridge I had some challenges with blocking API in the Kafka client (like pool) so used threads for that (for avoiding blocking the event loop) and other challenges related to when commit or not on Kafka due to AMQP interaction

[11:18:38] <temporal_> for the Consumer you have the choice to use event loop or worker thread

[11:18:44] <ppatiern> I think that my bridge is a good use case for checking what we need (or already have) in the Vert.x Kafka

[11:18:45] <temporal_> in case it is event loop

[11:18:52] <temporal_> for consumer or producer

[11:19:07] <temporal_> it uses a strategy to use exponential backoff idling

[11:19:11] <temporal_> i.e it retries some times

[11:19:15] <temporal_> with a yield

[11:19:23] <temporal_> then really does a pause

[11:21:47] <temporal_> ppatiern also I think some thigns should be configruable

[11:21:53] <temporal_> I need to add in readme

[11:22:10] <temporal_> like how many records are handled per event loop task in consumer

[11:22:12] <temporal_> now it is 10

[11:22:22] <temporal_> this is something user wants to configure

[11:22:29] <temporal_> to prioritize

[11:28:51] <ppatiern> sure

[11:30:16] <temporal_> ok done

[11:31:10] <ppatiern> so now the repo is updated right ?

[11:31:17] <ppatiern> no other changes are needed from your side

[13:02:57] <temporal_> ppatiern at the moment no

[16:10:56] <D-Spair> I would like some opinions… If none of the other Hazelcast features are a requirement for my project, would it be better to just use a NetSocket event bus bridge or TCP configured Hazelcast?

[16:16:12] <temporal_> D-Spair interetsing question

[16:16:28] <temporal_> if you just need a remote access to event bus you should use a bridge

[16:17:18] <D-Spair> temporal_: That's kinda what I was leaning toward… Fewer dependencies and less configuration overhead.

[16:17:24] <temporal_> yes

[16:17:28] <temporal_> and no multicast

[16:17:31] <myghty> temporal_: might be a real API gateway an interesting feature which might interest the vert.x community?

[16:17:41] <temporal_> myghty yes

[16:17:45] <D-Spair> Multicast is out of the question anyhow as we are deploying via Docker.

[16:17:51] <temporal_> are you looking for contributing something myghty

[16:18:04] <myghty> temporal_: well, I am working on an api gateway for my private project

[16:18:12] <myghty> and thought it might make sense to open it for everyone

[16:18:19] <temporal_> myghty I strted this https://github.com/vietj/vertx-http-proxy/

[16:18:32] <myghty> I know temporal_ :) we spoke about it multiple times ;D

[16:18:38] <temporal_> it aims to be a vert.x-y http proxy on top of which people can build http gateway kind of thigns :-)

[16:18:39] <temporal_> ok

[16:18:45] <temporal_> it has made some progress since maybe :-)

[16:18:48] <myghty> exactly that was what I was doing ;D

[16:19:00] <myghty> building a gateway on top of it

[16:19:04] <temporal_> would be great

[16:19:11] <temporal_> I have setup an opensource account with Co-Advisor

[16:19:18] <temporal_> an http proxy test suite

[16:19:28] <temporal_> http://coad.measurement-factory.com

[16:19:32] <myghty> ah cool, I, thanks for the hint

[16:19:40] <temporal_> and when I do have free time, I try to make more tests passing :-)

[16:19:58] <myghty> jea freetime is the most common issue

[16:20:20] <temporal_> in this case it's ok-ish as it is just running tests

[16:20:22] <temporal_> seing what is wrong

[16:20:22] <myghty> right now I developed the gateway for my client… therefore I have to reprogramm it from scratch for my private stuff as well… non disclosure and all that

[16:20:36] <temporal_> underwtand the problem read the spec

[16:20:43] <temporal_> write a test and make it pass :-)

[16:20:45] <temporal_> goto 1

[16:21:05] <temporal_> that being said it helped me to improve things in vertx core http layer a bit

[16:21:28] <temporal_> D-Spair there are plans to have at some point a pure java bridge client

[16:21:44] <temporal_> D-Spair if you are looking for doing a contribution, it may be an interesting one for you

[16:22:13] <temporal_> the idea is to have a client like for JS, etc… but in Java to be able to interact with event bus without having to form a cluster

[16:22:28] <temporal_> with minimal libs (ideally only JDK)

[16:22:28] <temporal_> could be used Android

[16:22:30] <temporal_> too

[16:22:32] <temporal_> etc…

[16:25:00] <D-Spair> I was looking into that the other day, the potential of using Vert.x for Android… The programming models seem like they would mesh well (Never block the event loop)…

[16:26:04] <D-Spair> temporal_: As for the pure Java event bus bridge, what would be different from using the NetSocker event bus bridge? Just trying to avoid using Netty and native libs?

[16:26:40] <temporal_> yes

[16:26:43] <temporal_> but that's just an opinion

[16:26:51] <temporal_> maybe it could use netty as well

[16:27:12] <temporal_> well actually it could be used with Netty I think

[16:27:14] <D-Spair> I'm not sure that Netty is much of a viable option on Android, is it?

[16:27:23] <temporal_> it would make sense to have two remote event bus interacting each other

[16:27:31] <temporal_> D-Spair it is AFAIR

[16:27:32] <D-Spair> Agreed!

[16:27:39] <temporal_> Vert.x however is different

[16:27:46] <temporal_> I don't remember whwy but there is a problem

[16:27:49] <temporal_> in android

[16:28:15] <D-Spair> Netty supports Android since 4.1

[16:28:49] <temporal_> yes

[16:29:35] <D-Spair> I would think that there must be something about the core Vert.x code which is using a JDK specific feature which is not available in ART or Dalvik…

[16:29:48] <temporal_> yes but I don't remember

[16:30:04] <temporal_> I need to go guys :-) it was good talking with you

[16:30:09] <D-Spair> Shouldn't be too difficult to locate…

[16:30:17] <temporal_> if you plan to contribute something, just reach us :-)

[16:30:20] <D-Spair> I'll see if I can have a look.

[16:31:00] <D-Spair> temporal_: I've already contributed some (docs, minor PRs) and have my contributor agreement on file with Eclipse Foundation..

[16:31:19] <temporal_> D-Spair nice!

[16:31:36] <D-Spair> I've also been talking with vietj about implementing an Erlang-style Supervisory system.

[16:32:09] <D-Spair> I'm also looking forward to Paulo's streaming DB improvements in 4.x

[16:32:53] <D-Spair> Right now, I have to launch a separate thread which uses JDBC or Groovy SQL to stream DB results which are too large for RAM…

[16:33:08] <myghty> oh gosh… I would love to contribute more guys… now you are making me want that even more :(

[16:33:17] <D-Spair> Not really difficult, but it would be AWESOME to have that functionality native to Vert.x

[16:36:21] <D-Spair> I'm fairly certain that the JDBC service is doing a separate thread per connection pool item anyhow… So, adding the ability to stream results to the event bus shouldn]

[16:36:28] <D-Spair> shouldn't be difficult…

[16:38:11] <D-Spair> In fact, I could problem submit a PR for that in almost NO TIME!

[16:38:22] <D-Spair> s/problem/probably/

[16:44:06] <temporal_> D-Spair I am vietj

[16:44:13] <temporal_> :-)

[16:44:17] <temporal_> so now I remember you :-)

[16:48:10] <D-Spair> NVM, Paulo already beat me to it… Looks like JDBC Streaming results are already there for 3.4.0

[16:49:08] <D-Spair> Anyone have an idea of when 3.4.0 will go GA?

[18:52:17] <temporal_> D-Spair first quarter 2017 rather early than late :-)

[19:42:09] <D-Spair> Kewl, good to know..

[19:50:39] <rruss> D-Spair: I'm guessing early 2017 :-)

[20:38:27] <temporal_> rruss yeah, we haven't yet decided if we are time boxed or feature boxed :-)

[20:45:38] <rruss> temporal_: that's why it's just a guess ;)