[11:48:52] <aesteve> Hello everyone. If anyone interested : https://github.com/aesteve/vertx-mvc/blob/master/README.md
[11:49:12] <aesteve> it's a kind of resteasy-like framework on top of Apex
[11:55:04] <temporalfox> you need a nickname maybe for the project
[11:55:25] <aesteve> I'm bad at nicknames :(
[11:55:39] <temporalfox> one awesome thing you could do is to generate URL builders
[11:55:46] <temporalfox> using annotation processing
[11:55:52] <temporalfox> I did that for my previous web framework
[11:56:11] <temporalfox> also annotation processing can help you save annotations
[11:56:19] <temporalfox> @Param(“type”) CharacterType type
[11:56:21] <aesteve> not sure I understand what an URL Builder is
[11:56:28] <temporalfox> something to build an URL
[11:56:31] <temporalfox> so you do
[11:56:33] <temporalfox> in java
[11:56:48] <temporalfox> CharactersController_.getCharacter(“foobar”);
[11:56:52] <temporalfox> and it returns an URL
[11:57:00] <temporalfox> CharactersController_ is a generated class
[11:57:11] <temporalfox> and the url builder uses the @Path info etc…
[11:57:26] <aesteve> mmh
[11:58:17] <temporalfox> if I would have time I would help you doing it
[11:58:17] <aesteve> how will I map the generated URL onto an Apex route ?
[11:58:35] <temporalfox> ah
[11:58:39] <temporalfox> it is for generating URL
[11:58:46] <temporalfox> not handling them
[11:59:03] <aesteve> ah ok
[11:59:03] <temporalfox> creating server URL from server side
[11:59:19] <aesteve> for now, every annotation is a runtime annotation
[11:59:40] <aesteve> when you bootstrap the “mvc” layer, it scans and instanciates all the apex stuff for you (basically)
[12:00:01] <aesteve> but I'm pretty sure I could benefit from non-runtime annotations !
[12:00:20] <temporalfox> with annotation processing you could remove need for @Param annotation
[12:00:23] <temporalfox> that repeats the name
[12:00:26] <temporalfox> like in Play1
[12:00:37] <temporalfox> because you have access to this info at compilation time
[12:01:12] <aesteve> so the name of the java parameter would be the name of the request/route parameter ?
[12:01:19] <aesteve> would be awesome indeed
[12:01:30] <temporalfox> yes
[12:02:55] <aesteve> cool, I'll create an issue so that I don't forget
[12:05:12] <aesteve> thanks :)
[13:46:21] <temporalfox> purplefox_ I have a question for you
[14:06:52] <purplefox_> temporalfox: sure
[14:07:19] <temporalfox> I'm wrapping a java lib that gathers OS info, like process, cpu, etc…
[14:07:29] <temporalfox> for a demo
[14:07:40] <temporalfox> it's called “sigar”
[14:07:59] <temporalfox> I would like to have a node able to fetch info regularly from a cluster
[14:08:20] <temporalfox> right now a sigar verticle published a bus address in the shared data map
[14:08:42] <temporalfox> and then a node that wants such info can query send a message and get a reply with the info
[14:08:49] <temporalfox> do you have something simpler in mind ?
[14:09:11] <purplefox_> shared data local map? that's only local to the vert.x instance
[14:09:20] <temporalfox> clustered map
[14:09:27] <temporalfox> vertx.sharedData().getClusterWideMap
[14:10:32] <purplefox_> ok
[14:10:54] <purplefox_> why not just have a well known address and have the verticle publish stats to that, then others can subscribe to that address?
[14:11:25] <temporalfox> ok
[14:11:30] <temporalfox> I was thinking at this
[14:11:40] <temporalfox> however the node that gets data, does not know the topology
[14:11:56] <temporalfox> ideally it aggregates data and then send it to the client
[14:12:09] <temporalfox> it can however gather data
[14:12:17] <temporalfox> and send the updated aggregated view every second
[14:12:31] <temporalfox> and takes whatever has been published during that timeframe
[14:12:43] <temporalfox> so I will try htat instead
[14:13:08] <purplefox_> i guess i'm not sure i understand your topology
[14:13:38] <temporalfox> servers on the cluster start a SigarVerticle that publishes OS metrics
[14:13:55] <temporalfox> and one node of the cluster gathers them all and then send it to the browser for doing charting
[14:16:22] <purplefox_> ok
[14:35:28] <aesteve> purplefox_: hello, I was wondering something I can't find in the docs, is there a way to “join” futures ?
[14:36:22] <aesteve> like : i want to do A, and B : and once A and B are finished, I'm ready to do something
[14:37:15] <aesteve> I did that here for example : https://github.com/aesteve/vertx-mvc/blob/bfa56b2576c42f6fede9c6391e77e62e0af32632/src/main/java/io/vertx/mvc/utils/MultipleFutures.java
[15:20:27] <temporalfox> aesteve you can use RxJava for that
[15:20:44] <temporalfox> and the Rxified api
[15:22:10] <aesteve> ok I'll have a look, thanks tekacs
[15:22:21] <aesteve> oops, thanks temporalfox :\
[19:47:35] <AlexLehm> in case you haven't read that already, take a look at https://com.google/
[20:13:34] <voidDotClass> lol
[20:14:11] <voidDotClass> is .google a tld?
[21:01:29] <voidDotClass> purplefox_: temporalfox : Why does the static file handler create a .vertx/file-cache-xxx directory / files?
[21:01:43] <voidDotClass> Shouldnt it cache the stuff in memory? After all the static files are meant to be static
[21:01:50] <voidDotClass> what's it writing to disk?
[21:03:47] <purplefox_> static doesn't mean the files don't change. e.g. it's pretty common to edit a something.html file on a website and have the change picked up without restarting the server
[21:04:21] <purplefox_> static just means the files aren't dynamic, i.e. they're not created on the fly with e.g. templates
[21:04:37] <voidDotClass> but they are packed in a jar
[21:04:40] <voidDotClass> they cant change
[21:04:56] <temporalfox> if you use the CLI it can change
[21:05:02] <temporalfox> I'm doing that at the moment :)
[21:05:13] <voidDotClass> would you do that in prod?
[21:05:19] <voidDotClass> caching is only useful for prod
[21:05:25] <temporalfox> good point
[21:05:35] <temporalfox> I'm not an apex specialist yet though
[21:11:28] <purplefox_> static handler has cache headers enabled so if it hasn't changed then it won't serve the file again anyway
[21:11:41] <purplefox_> (i.e. using if-modified-since)
[21:11:56] <voidDotClass> purplefox_: but what is it writing to disk?
[21:12:13] <purplefox_> we extract to disk because:
[21:12:24] <purplefox_> a) it's much faster to serve from disk than to extract from a jar
[21:13:19] <voidDotClass> If you are running within a jar, isn't class.getResourceAsStream() or equivalent, just getting it from memory?
[21:13:34] <purplefox_> b) don't want to fill memory with lots of files
[21:13:40] <purplefox_> you might have gigabytes of files
[21:14:01] <purplefox_> class.getResourceAsStream() depending on where the resources is might end up unzipping a jar
[21:14:09] <purplefox_> also its blocking
[21:14:27] <purplefox_> sendFile from disk is the most efficient way to serve files
[21:14:37] <purplefox_> it actually bypasses userspace altogether in most cases
[21:15:11] <voidDotClass> so you're reading the file from jar the first time, writing it to disk, then reading it from disk and serving it from disk from then on?
[21:15:18] <purplefox_> yes
[21:15:28] <purplefox_> but it's not necessarily in a jar in the first place
[21:15:38] <purplefox_> it could be elsewhere on the classpath or not on the classpath at all
[21:15:47] <purplefox_> but in some cases (e.g. fatjars) it might be in a jar
[21:22:11] <voidDotClass> i see
[21:30:48] <purplefox_> temporalfox: i have some auth and apex changes almost ready, but won't be ready until tomorrow morning. will they be in time for the release?
[21:30:57] <temporalfox> yes
[21:31:02] <voidDotClass> which release?
[21:31:02] <temporalfox> I will do the release friday
[21:31:06] <temporalfox> milestone4
[21:31:07] <purplefox_> ok great.
[21:31:18] <temporalfox> can you validate my tiny metrics changes ?
[21:31:18] <purplefox_> michel has also provided a PR for the website :)
[21:31:32] <temporalfox> yes that's providence
[21:31:42] <temporalfox> I mean totally awesome
[21:32:17] <purplefox_> +1
[21:32:47] <purplefox_> +100
[22:35:12] <AlexLehm> voidDotClass, i assume .google is a tld controlled by google onl
[22:35:33] <voidDotClass> yeah seems they acquired the .tld