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

[11:48:52] <aesteve> Hello everyone. If anyone interested :

[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 :

[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

[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