Differences

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

Link to this comparison view

— irc:1444773600 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[01:49:35] *** ChanServ sets mode: +o purplefox
 +
 +[02:50:07] *** ChanServ sets mode: +o purplefox
 +
 +[09:28:20] *** ChanServ sets mode: +o purplefox
 +
 +[09:40:57] <temporalfox> jtruelove hi
 +
 +[09:41:17] <temporalfox> pmlopes hi I have a couple of questions for you
 +
 +[09:41:34] <pmlopes> hi
 +
 +[09:42:45] <temporalfox> in vertx.x web or redis/jdbc do we have use case with List/Set containing null ?
 +
 +[09:43:40] <pmlopes> as argument or as reply?
 +
 +[09:43:54] <temporalfox> both :-)
 +
 +[09:43:54] <pmlopes> or it doesn't matter?
 +
 +[09:44:08] <temporalfox> I'm figuring out the current javascript support for nullable
 +
 +[09:44:38] <temporalfox> and the reality of the current apis
 +
 +[09:44:44] <temporalfox> if we really need/use this feature
 +
 +[09:45:00] <temporalfox> I believe it makes sense for data stuff that can have null return or null insert
 +
 +[09:45:37] <temporalfox> as you worked a bit on database stuff (redis / jdbc) I wnated to check with your the use cases
 +
 +[09:45:40] <pmlopes> i am looking at redis code and a list might contain null values since it is a perfect valid for redis
 +
 +[09:45:53] <temporalfox> if we need it and then we need to properly support it in the codegen TCK
 +
 +[09:45:54] <pmlopes> i even need to encode them in a special way
 +
 +[09:46:13] <temporalfox> ok
 +
 +[09:46:21] <temporalfox> so that would be an argument
 +
 +[09:46:33] <pmlopes> oh and i know that we also need it for the jdbc client
 +
 +[09:46:46] <temporalfox> what type is it ?
 +
 +[09:46:55] <temporalfox> List<String> ?
 +
 +[09:47:21] <pmlopes> oh no, for jdbc it is a json array
 +
 +[09:47:34] <temporalfox> json is different
 +
 +[09:47:43] <pmlopes> when you have query placeholders ? they can be null
 +
 +[09:47:57] <temporalfox> so what do we have for List/Set/Map ?
 +
 +[09:48:43] <pmlopes> humm in that case we could deprecate the redis API and propose a new one using JsonArray
 +
 +[09:49:17] <temporalfox> jdbc seems to use JsonArray
 +
 +[09:49:20] <pmlopes> for a quick find and count it seems that we would need to deprecate 34 method :|
 +
 +[09:49:20] <temporalfox> in SQLConnection
 +
 +[09:49:40] <temporalfox> pmlopes what do you mean ?
 +
 +[09:49:56] <pmlopes> no, sorry in redis, in redis
 +
 +[09:50:40] <pmlopes> in redis there are 34 methods that take List<String> and they can have both null or not null values, however i think we could propose a API update to replace that with JsonArray
 +
 +[09:51:02] <temporalfox> like
 +
 +[09:51:03] <temporalfox> RedisClient evalsha(String sha1, List<String> keys, List<String> values, Handler<AsyncResult<JsonArray>> handler);
 +
 +[09:51:10] <pmlopes> yes
 +
 +[09:51:12] <temporalfox> I think it's fine to have nullable
 +
 +[09:51:28] <temporalfox> if it's string I think List<String> is better
 +
 +[09:51:32] <temporalfox> and we should keep it
 +
 +[09:51:44] <temporalfox> my point isthat I'm not sure JavaScripr properly supports null in lists
 +
 +[09:52:01] <pmlopes> ['a', null] is perfectly valid
 +
 +[09:52:27] <temporalfox> ok
 +
 +[09:52:41] <temporalfox> I think we miss at least TCK use cases
 +
 +[09:52:50] <temporalfox> for testing such behavior cross languages
 +
 +[09:53:06] <pmlopes> even more weird stuff like ['a', null, undefined] is allowed ;) don't you love it now :)
 +
 +[09:53:27] <temporalfox> but that would not make sense for vertx
 +
 +[09:53:40] <temporalfox> and that would result in some kind of errors thrown by vertx-lang-js
 +
 +[09:53:45] <temporalfox> wouldn't it ,
 +
 +[09:54:40] <pmlopes> it depends if someone is checking for nulls with == then null or undefined are considered null, however if one checks with === then only null is null
 +
 +[09:55:07] <temporalfox> that's why we need a TCK :-)
 +
 +[09:55:08] <pmlopes> the bad side is that if one uses == then 0, '', false are also null :)
 +
 +[09:55:17] <temporalfox> at the moemnt we use typeof on arguments
 +
 +[09:55:29] <temporalfox> and I know that type null is "object"
 +
 +[09:55:32] <temporalfox> in JS
 +
 +[09:55:39] <temporalfox> and the shim is ok with that
 +
 +[09:55:45] <temporalfox> then there is a null check in the conversion
 +
 +[09:55:55] <temporalfox> that means today we don't accept null functions
 +
 +[09:56:10] <temporalfox> for instance vertx.close(null) is acceptable by Vert.x core
 +
 +[09:56:20] <temporalfox> in JS vertx.close(null) throws a TypeError
 +
 +[09:56:21] <pmlopes> where can i add javascript TCK tests?
 +
 +[09:56:33] <temporalfox> that would rather be custom JS cases I think
 +
 +[09:56:36] <temporalfox> as they would contain null
 +
 +[09:56:45] <temporalfox> like you do a Vert.x API in JS
 +
 +[09:56:49] <temporalfox> codegen
 +
 +[09:56:55] <temporalfox> like
 +
 +[09:57:02] <temporalfox> checkList(List<String>)
 +
 +[09:57:06] <temporalfox> and you call it with undfined
 +
 +[09:57:10] <temporalfox> and see what happens :-)
 +
 +[09:57:15] <temporalfox> (tdd style)
 +
 +[09:57:29] <temporalfox> TCK would be more for Nullable collections
 +
 +[09:58:21] <pmlopes> the best way to test for null in js would be (if value === null || value === undefined)
 +
 +[09:58:46] <pmlopes> then we have a behavior like java for instance
 +
 +[10:00:49] <temporalfox> ah you mean that undefined would be considered as null ?
 +
 +[10:01:20] <pmlopes> yes
 +
 +[10:02:03] <pmlopes> and i think that for most use cases in js that is fine specially it what matters to call vert.x code
 +
 +[10:04:49] <temporalfox> yes we should rather be permissive if we pass undefined explictely
 +
 +[10:05:01] <temporalfox> as long as it does not have impacts on overloading :-)
 +
 +[10:07:01] <pmlopes> how do you run the TCK?
 +
 +[10:08:51] *** ChanServ sets mode: +o purplefox
 +
 +[10:09:37] <temporalfox> mvn clean test
 +
 +[10:09:42] <temporalfox> TCK is ApiTest
 +
 +[10:09:49] <temporalfox> then you have extra tests around
 +
 +[10:09:53] <temporalfox> to test special cases in JS
 +
 +[10:09:58] <temporalfox> and that what you would do
 +
 +[10:10:13] <temporalfox> but before working on that we should first agree on the global nullable behavior :-)
 +
 +[10:10:24] <temporalfox> cf my point about nullable function/handler
 +
 +[10:12:58] <pmlopes> currently in core handlers are not optional, they do not take nulls so we can do the same for JS if handler === null or handler ===undefied then it is a type error i think
 +
 +[10:14:08] <pmlopes> the undefined is important for cases like: redis.get('key') since i did not pass a second arg js will interpret the second arg as undefined
 +
 +[10:22:33] <purplefox> pmlopes: temporalfox cescoffier: morning guys
 +
 +[10:22:42] <temporalfox> hi
 +
 +[10:22:43] <pmlopes> good morning
 +
 +[10:22:43] <cescoffier> morning
 +
 +[10:23:00] <temporalfox> pmlopes null handler has impact on overloading check
 +
 +[10:23:22] <temporalfox> pmlopes and yes some handlers are optional
 +
 +[10:23:28] <temporalfox> for instance : vertx.close(null) is valid
 +
 +[10:23:42] <temporalfox> if you look at Pump implemnetation
 +
 +[10:23:48] <temporalfox> it calles an handler with null value
 +
 +[10:27:01] <pmlopes> can you share an example where you're having trouble with js maybe it would be easier for me to fully understand the problem
 +
 +[10:27:02] <cescoffier> purplefox, pmlopes, temporalfox : if you all agree with the tags proposal, I will update the wiki
 +
 +[10:27:18] <pmlopes> @cescoffier +1 for the tags
 +
 +[10:27:26] <temporalfox> pmlopes I sent an example on vertx-dev in reply to myself :-)
 +
 +[10:27:37] <pmlopes> ok
 +
 +[11:44:31] <purplefox> temporalfox: hi julien
 +
 +[11:44:41] <purplefox> temporalfox: quick question on EventBusMetrics:
 +
 +[11:44:45] <purplefox> void messageSent(String address, boolean publish, boolean local, boolean remote);
 +
 +[11:45:05] <purplefox> can "local" and "remote" ever be the same?
 +
 +[11:45:15] <purplefox> if so, why are there two params?
 +
 +[11:55:07] <temporalfox> purplefox it can be true/true in case of publish that publish both locally and remote on cluster
 +
 +[11:56:05] <temporalfox> we should update javadoc to be more precise for implementors
 +
 +[12:01:29] <purplefox> ok, i see thanks
 +
 +[12:01:57] <cescoffier> pmlopes: did you change the configuration of the vertx-examples build ?
 +
 +[12:02:24] <pmlopes> i don't think so, why?
 +
 +[12:02:34] <cescoffier> the build became parameterized
 +
 +[12:02:40] <cescoffier> by the branch to build
 +
 +[12:03:12] <cescoffier> well... removing it :-)
 +
 +[12:03:24] <pmlopes> no i did not do anything on jenkins lately specially about parameterized builds
 +
 +[12:03:27] <pmlopes> ok
 +
 +[12:04:26] <cescoffier> the build is failing with "no workspace for vert.x3-examples #640"
 +
 +[12:10:15] <pmlopes> we also get timeout building web on jenkins it takes more than 30 minutes...
 +
 +[12:10:18] <cescoffier> ok found the culprit ... the github pull request plugin failed
 +
 +[12:10:27] <cescoffier> 30 minutes !
 +
 +[12:10:34] <cescoffier> wow, I already increase the timeout
 +
 +[12:10:40] <cescoffier> 30 min is regally huge
 +
 +[12:10:47] <pmlopes> yes that is quite stange since it builds in less than 5 on my local machine
 +
 +[12:10:55] <pmlopes> doing everything including docs
 +
 +[12:13:13] <pmlopes> there was something wrong with sockjs tests and they blocked for 30 minutes
 +
 +[12:13:31] <pmlopes> Starting test: SockJSHandlerTest#testNotFound
 +
 +[12:13:33] <pmlopes> io.vertx.core.VertxException: Connection was closed
 +
 +[12:13:36] <pmlopes> Thread Thread[vert.x-eventloop-thread-8,5,main] has been blocked for 2990 ms, time limit is 2000
 +
 +[12:13:38] <pmlopes> Thread Thread[vert.x-eventloop-thread-6,5,main] has been blocked for 2989 ms, time limit is 2000
 +
 +[12:13:40] <pmlopes> Thread Thread[vert.x-eventloop-thread-8,5,main] has been blocked for 3990 ms, time limit is 2000
 +
 +[12:13:42] <pmlopes> Thread Thread[vert.x-eventloop-thread-6,5,main] has been blocked for 3990 ms, time limit is 2000
 +
 +[12:13:44] <pmlopes> Thread Thread[vert.x-eventloop-thread-8,5,main] has been blocked for 4991 ms, time limit is 2000
 +
 +[12:13:45] <pmlopes> Thread Thread[vert.x-eventloop-thread-6,5,main] has been blocked for 4991 ms, time limit is 2000
 +
 +[12:13:48] <pmlopes> Thread Thread[vert.x-eventloop-thread-8,5,main] has been blocked for 5990 ms, time limit is 2000
 +
 +[12:13:50] <pmlopes> io.vertx.core.VertxException: Thread blocked
 +
 +[12:13:52] <pmlopes> at io.vertx.core.http.impl.ClientConnection.endRequest(ClientConnection.java:339)
 +
 +[12:13:54] <pmlopes> at io.vertx.core.http.impl.HttpClientRequestImpl.connected(HttpClientRequestImpl.java:552)
 +
 +[12:13:56] <pmlopes> at io.vertx.core.http.impl.HttpClientRequestImpl.lambda$connect$72(HttpClientRequestImpl.java:515)
 +
 +[12:13:58] <pmlopes> at io.vertx.core.http.impl.HttpClientRequestImpl$$Lambda$15/1101184763.handle(Unknown Source)
 +
 +[12:14:00] <pmlopes> at io.vertx.core.http.impl.ConnectionManager$ConnQueue.lambda$getConnection$55(ConnectionManager.java:92)
 +
 +[12:14:02] <pmlopes> at io.vertx.core.http.impl.ConnectionManager$ConnQueue$$Lambda$128/234250762.handle(Unknown Source)
 +
 +[12:14:04] <pmlopes> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:335)
 +
 +[12:14:06] <pmlopes> at io.vertx.core.impl.ContextImpl$$Lambda$12/1908698042.run(Unknown Source)
 +
 +[12:14:08] <pmlopes> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
 +
 +[12:14:10] <pmlopes> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
 +
 +[12:14:12] <pmlopes> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
 +
 +[12:14:14] <pmlopes> at java.lang.Thread.run(Thread.java:745)
 +
 +[12:14:18] <pmlopes> Thread Thread[vert.x-eventloop-thread-6,5,main] has been blocked for 5990 ms, time limit is 2000
 +
 +[12:14:20] <pmlopes> io.vertx.core.VertxException: Thread blocked
 +
 +[12:14:22] <pmlopes> at io.vertx.core.http.impl.HttpClientRequestImpl.handleException(HttpClientRequestImpl.java:326)
 +
 +[12:14:24] <pmlopes> at io.vertx.core.http.impl.ClientConnection.handleClosed(ClientConnection.java:307)
 +
 +[12:14:26] <pmlopes> at io.vertx.core.net.impl.VertxHandler$$Lambda$28/1528776789.run(Unknown Source)
 +
 +[12:14:27] <pmlopes> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:333)
 +
 +[12:14:30] <pmlopes> at io.vertx.core.impl.ContextImpl$$Lambda$12/1908698042.run(Unknown Source)
 +
 +[12:14:32] <pmlopes> at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:225)
 +
 +[12:14:33] <pmlopes> at io.vertx.core.net.impl.VertxHandler.channelInactive(VertxHandler.java:99)
 +
 +[12:14:36] <pmlopes> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:208)
 +
 +[12:14:38] <pmlopes> at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:194)
 +
 +[12:14:40] <pmlopes> at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:306)
 +
 +[12:14:42] <pmlopes> at io.netty.handler.codec.http.HttpClientCodec$Decoder.channelInactive(HttpClientCodec.java:212)
 +
 +[12:14:44] <pmlopes> at io.netty.channel.CombinedChannelDuplexHandler.channelInactive(CombinedChannelDuplexHandler.java:132)
 +
 +[12:14:45] <pmlopes> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:208)
 +
 +[12:14:48] <pmlopes> at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:194)
 +
 +[12:14:49] <pmlopes> at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:828)
 +
 +[12:14:52] <pmlopes> at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:621)
 +
 +[12:14:54] <pmlopes> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
 +
 +[12:14:56] <pmlopes> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
 +
 +[12:14:57] <pmlopes> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
 +
 +[12:15:00] <pmlopes> at java.lang.Thread.run(Thread.java:745)
 +
 +[12:15:02] <pmlopes> and the it stays there for 30 minutes printing the same exception
 +
 +[12:17:02] <purplefox> get a stack dump
 +
 +[12:17:07] <purplefox> it might be a deadlock
 +
 +[13:06:43] <purplefox> temporalfox: another EventBusMetrics question:
 +
 +[13:06:44] <purplefox> void handlerUnregistered(H handler);
 +
 +[13:07:19] <purplefox> What is the argument passed in here? It appears to be untyped
 +
 +[13:09:52] <temporalfox> the argument is the object returned by handlerRegistered, which is a callback object of the implementation
 +
 +[13:14:05] <purplefox> why does the metrics need to know that?
 +
 +[13:31:29] <temporalfox> because it makes the SPI implementation typed and avoid casts
 +
 +[13:31:59] <temporalfox> for instance
 +
 +[13:32:00] <temporalfox> https://github.com/vert-x3/vertx-dropwizard-metrics/blob/master/src/main/java/io/vertx/ext/dropwizard/impl/EventBusMetricsImpl.java
 +
 +[13:32:17] <temporalfox> public void handlerUnregistered(HandlerMetric handler) {
 +
 +[15:26:48] <melvinross> is there anyway to use npm modules with js vertx in conjunction with maven?
 +
 +[15:42:19] <melvinross> or just through regular vertx run?
 +
 +[15:43:32] <pmlopes>   @melvinross you can use npm modules with maven at least like this: https://mrhanlon.com/posts/using-npm-bower-and-grunt-with-maven/
 +
 +[15:43:56] <pmlopes> or if your code is just javascript you can just use npm
 +
 +[15:45:21] <pmlopes> http://vertx.io/blog/vert-x3-says-hello-to-npm-users/
 +
 +[15:49:43] <melvinross> yeah, i was just trying to avoid it since it means adding nodejs as a deployment dependency
 +
 +[15:50:38] <melvinross> i wonder how that maven solution will work with creating fat jars
 +
 +[15:51:46] <cescoffier> melvinross: what kind of npm modules do you want to use ?
 +
 +[15:52:16] <cescoffier> melvinross: if you just want to resolve them and embed them in a fat jat, you can use the frontend-maven-plugin
 +
 +[15:52:35] <cescoffier> melvinross: this plugin installs node locally, and is able to resolve npm modules
 +
 +[15:52:47] <cescoffier> (it can also call grunt, bower or gulp)
 +
 +[15:53:05] <melvinross> at the moment, the elastic search module. i may just write an async http client
 +
 +[15:53:53] <cescoffier> you can do it using the front-maven-plugin then.
 +
 +[15:54:04] <cescoffier> sorry: frontend-maven-plugin
 +
 +[15:54:15] <cescoffier> https://github.com/eirslett/frontend-maven-plugin
 +
 +[15:55:13] <cescoffier> you configure it to retrieve node and npm, and then a second execution to resolve your npm
 +
 +[15:55:30] <cescoffier> if you place them in the right directory, it should work smoothly
 +
 +[15:56:06] <melvinross> thanks for the suggestions
 +
 +[15:56:11] <alvaro_sanchez> purplefox: I will be pushing code for my talk [unknown:ldquo]Vert.x vs Ratpack[unknown:rdquo] in this repo: https://github.com/alvarosanchez/vertx-vs-ratpack
 +
 +[15:56:28] <alvaro_sanchez> any feedback will be appreciated :)
 +
 +[16:03:22] <cescoffier> alvaro_sanchez: how are you starting the vert.x app ?
 +
 +[16:04:15] <alvaro_sanchez> at the moment I just have a hello world. I will create proper gradle-based applications in the following days
 +
 +[16:08:04] <cescoffier> if you use a fat jar, you don't need the @Grab
 +
 +[16:12:35] <alvaro_sanchez> yeah I know, I just wanted to have that running directly
 +
 +[16:13:13] <alvaro_sanchez> making a JAR doesn't prove the point for a hello world (ie: it's an additional step)
 +
 +[16:15:39] <alvaro_sanchez> I just created that repo, and the hello worlds are just the first step
 +
 +[16:15:57] <alvaro_sanchez> but my goal is to write a simple REST API in both techs
 +
 +[16:16:38] <alvaro_sanchez> and they'll be proper gradle-based projects, thus no more Grab's
 +
 +[16:17:30] <cescoffier> cool
 +
 +[16:17:35] <cescoffier> will follow ti
 +
 +[16:18:26] <alvaro_sanchez> thanks!
 +
 +[16:54:56] <melvinross__> cescoffier: thanks for the help. it ended up being a bit of a bust, it can load the module, but fails on relative loads from the module itself, but it was a good exercise
 +
 +[16:55:47] <cescoffier> you embed all the modules in the fat jar ?
 +
 +[16:55:57] <melvinross__> yeah
 +
 +[16:56:29] <melvinross__> the files definitely in there. can see it in file-roller
 +
 +[16:57:26] <cescoffier> oh I see, one of the NPM modules is calling 'requires'
 +
 +[16:57:34] <melvinross__> yep
 +
 +[16:57:39] <cescoffier> we may not support this case yet
 +
 +[16:57:47] <cescoffier> as it's our own 'requires'
 +
 +[16:59:01] <melvinross__> in case you were wondering, the easiest way i found to get the node modules into the fat jar via shader was to change the workingDirectory to being inside of src/js
 +
 +[16:59:20] <cescoffier> pmlopes: are you around ?
 +
 +[16:59:40] <cescoffier> Paulo knows much more things about node, so he may see the issue
 +
 +[17:04:30] <jtruelove> temporalfox, big takeaways on hawkular?
 +
 +[17:04:40] <temporalfox> jtruelove hi
 +
 +[17:04:51] <temporalfox> actually we drawed a path toward inclusion in stack for 3.2
 +
 +[17:05:04] <temporalfox> and we also discussed possiblity to have a single metrics project
 +
 +[17:05:14] <temporalfox> containing dropwizard, hawkular in the future
 +
 +[17:05:20] <jtruelove> interesting
 +
 +[17:05:23] <temporalfox> and perhaps your work
 +
 +[17:05:26] <temporalfox> to share  things
 +
 +[17:05:31] <temporalfox> like configuration option
 +
 +[17:05:53] <jtruelove> yeah i put together vertx-bosun as well which is still pretty immature
 +
 +[17:05:54] <temporalfox> for instance, in dropwizard it's possible to define which server URI are reported
 +
 +[17:06:06] <temporalfox> so there is a Match Data Object
 +
 +[17:06:14] <temporalfox> and hawkular plans to have something similar
 +
 +[17:06:23] <temporalfox> would make sense to have something common with unified configuration
 +
 +[17:06:45] <jtruelove> gotcha yeah opentsdb is very generic it's just a time series db that allows for tagging data points
 +
 +[17:06:47] <temporalfox> in your case, I see hawkular reporting and opentsdb reporting having similar design with timer
 +
 +[17:06:59] <temporalfox> would be possible to have somethign common
 +
 +[17:07:11] <temporalfox> and just change the actual reporting
 +
 +[17:07:20] <jtruelove> yeah i think i'll keep the verticle for listening right now and then everyone publishing to it
 +
 +[17:07:28] <temporalfox> jtruelove ok
 +
 +[17:07:42] <jtruelove> otherwise i'd have to elect one instance as 'the' consumer
 +
 +[17:08:07] <temporalfox> I think in this case the actual reporter could be a straight client (using httpclient for instance)
 +
 +[17:08:08] <jtruelove> which isn't the worst but it kinda of overloads one thread with all the reporting work + whatever else it's doing
 +
 +[17:08:10] <temporalfox> or the event bus
 +
 +[17:08:18] <temporalfox> it would not matter
 +
 +[17:08:26] <temporalfox> the common stuff would just filter and collect metrics
 +
 +[17:08:40] <temporalfox> and timely flush this to the actual TSDB
 +
 +[17:08:51] <temporalfox> (for TSDB I mean hawkular or opentsdb or influx or...)
 +
 +[17:08:59] <jtruelove> yeah and that works as long as you generically collect
 +
 +[17:09:04] <temporalfox> there are many these days :-)
 +
 +[17:09:08] <jtruelove> it's true
 +
 +[17:09:20] <jtruelove> so that all the info you need is there when it hits the reporter
 +
 +[17:09:28] <temporalfox> yes
 +
 +[17:09:40] <temporalfox> I don't think we have time for this in 3.2
 +
 +[17:09:48] <temporalfox> as thomas needs first to finish his stuff
 +
 +[17:09:56] <temporalfox> and 3.2 is for end of novebmer
 +
 +[17:10:15] <temporalfox> but after, I think consolidation is definitely interesting
 +
 +[17:10:29] <temporalfox> (pretty much like vertx-auth consolidates Shiro, Mongo or Jdbc auth)
 +
 +[17:25:46] <jtruelove> yeah and i'm more than happy to help out
 +
 +[17:26:05] <jtruelove> first step is just wrapping up vertx-opentsdb so it can be used by SPI
 +
 +[17:26:15] <jtruelove> as writing timing metrics in your code is a pain in the ass
 +
 +[17:59:13] <jtruelove> temporalfox once you get the docs on how to integrate with vertx gen i can incorporate that stuff as right now i see the annotations but don't know where to start
 +
 +[18:01:03] <jtruelove> have you seen the stuff we are doing with exovert at all? https://github.com/cyngn/exovert
 +
 +[18:06:52] <temporalfox> jtruelove what do you expect from these docs exactly ?
 +
 +[18:15:36] <jtruelove> just a walk through / tutorial on how to use and support the code generation features
 +
 +[18:47:17] <temporalfox> so you mean for writing a polyglot API ?
 +
 +[18:47:24] <temporalfox> jtruelove so you mean for writing a polyglot API ?
 +
 +[18:48:21] <jtruelove> yeah more less
 +
 +[18:48:27] <jtruelove> err or less
 +
 +[18:48:49] <temporalfox> what is your goal ?
 +
 +[18:48:56] <jtruelove> although as long as your library uses the event bus you can sorta get that anyway
 +
 +[18:48:56] <temporalfox> I mean what would you do better with that ?
 +
 +[18:49:19] <jtruelove> i guess if you want your library usable from any of the vertx languages you'd need that right?
 +
 +[18:49:35] <temporalfox> what it buys is to have a polyglot API
 +
 +[18:49:40] <temporalfox> so you have typed client
 +
 +[18:49:48] <temporalfox> it can also use event bus with service proxies
 +
 +[18:50:22] <temporalfox> so you have polyglot service proxies that invoke via event bus the underlying service
 +
 +[18:50:50] <jtruelove> yeah that is what i was alluding to more or less with the event bus comment above
 +
 +[18:50:59] <temporalfox> ok
 +
 +[18:50:59] <temporalfox> the current guide talks more about the concept of codegen which are targetted from shim implementors
 +
 +[18:51:06] <temporalfox> but it should / could be read by api designers
 +
 +[18:51:17] <temporalfox> there should be a complementary guide for api authoring
 +
 +[18:51:26] <temporalfox> that explains the setup
 +
 +[18:51:36] <jtruelove> like so you want a niced typed metric publisher for any lang even though you deploy the consumer in java etc..
 +
 +[18:52:01] <jtruelove> how you would get that is with the gen stuff it seems
 +
 +[18:52:21] <jtruelove> granted they could look at the docs and see oh i can write my own i send to this topic with this message structure
 +
 +[18:52:28] <jtruelove> it just lowers the barriers to use etc..
 +
 +[21:13:10] *** ChanServ sets mode: +o purplefox