[17:25:47] <temporal_> ppatiern hey how is it going ?
[17:25:54] <temporal_> jtakvori yo!
[17:26:58] <jtakvori> Hi Julien
[17:29:34] <ppatiern> temporal_ fine thanks ! you ?
[17:34:26] <temporal_> ppatiern how is going the mqtt server progression ?
[17:36:24] <ppatiern> temporal_ I'm into the Eclipse Hono source code because it should be the first application of the mqtt server. It could be a good test for improving it.
[17:36:42] <temporal_> ppatiern ok
[17:36:55] <temporal_> jtakvori so you are doing some ceylon / vertx debugging :) ?
[17:38:41] <jtakvori> Yep I love buzz words :)
[17:40:46] <jtakvori> temporal_, so as I understand we'll have to use the next release to use ceylon 1.3 (or use snapshot, but I haven't found yet how to use snapshots in the ceylon module files
[17:41:26] <temporal_> jtakvori ceylon modulesdoes not have notion of snapshots
[20:12:54] <myghty> temporal_: hey there! :) Just a short question: is there any recommendation, on how to build an application utiizing several verticles? I mean: in the spring world e.g. you have a single point of entry, an API gateway e.g. that knows about all the service endpoints available and routes requests to the corresponding jvms afaik, vertx does not provide such single point of entry, but building one should not be to hard thanks to service registry and discovery. :) But
[20:13:36] <temporal_> myghty I think the best place to ask this is google group
[20:13:37] <myghty> I have seen people using a router singleton and then just deploying all verticles in one jvm and notifying the router about the new service endpoints but I think that would not be ideal since that will not scale over multiple maschines
[20:13:59] <myghty> temporal_: will do :) thought you might have a quick answer to that in your pocket ;)
[20:14:00] <temporal_> myghty also it might create a threading issue
[20:14:10] <myghty> exactly, that was what I thought
[20:14:26] <temporal_> I think the router should have some kind of plugins
[20:14:37] <myghty> atm I created a single point of entry verticle which then just forwards requests to the other jvms like a small reverse proxy
[20:14:39] <temporal_> or you would make them modular using class / instances
[20:14:45] <temporal_> and use lambda to mount them
[20:15:03] <temporal_> ah ok
[20:15:03] <myghty> but than it would not scale over multiple maschines again afaik
[20:15:06] <temporal_> is it http based ?
[20:15:11] <myghty> right now, yes
[20:15:21] <temporal_> I've created this project
[20:15:21] <temporal_> https://github.com/vietj/vertx-reverse-proxy
[20:15:26] <temporal_> more like a personal project
[20:15:28] <myghty> jep
[20:15:32] <myghty> I mostly oriented there
[20:15:32] <temporal_> that aims to be a dynamic router
[20:15:36] <temporal_> using discovery
[20:15:45] <temporal_> with a notion of back-end
[20:16:10] <temporal_> it's not really advanced but it shows what I'd like to do
[20:16:24] <temporal_> the goal is to expose microservices among all
[20:16:33] <temporal_> using vertx discovery
[20:16:43] <myghty> jep
[20:16:48] <myghty> that is what I did as well
[20:17:10] <myghty> one could also terminate the http connection there
[20:17:33] <myghty> and then use the service proxy, then every verticle would need to implement a “handlehttprequest” method or something
[20:18:07] <myghty> but then it would be limited to that, with solely forwarding http it would be more flexible and could also integrate services provided via classic applications running on servers such as weblogic :)
[20:18:33] <myghty> thanks :) then I am on the right track :)
[20:20:14] <myghty> btw temporal_ will you attend w-jax?
[21:16:50] *** ChanServ sets mode: +o temporalfox