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

[10:09:48] <eli_> hi, could you help me please? Can i make dynamic handler(implmented function) in vert.x js?

[10:17:50] <eli_> What means a “this” on vertx inside function?

[12:12:08] <msavy> hey temporalfox, apologies for prodding - but have you had any thoughts on this thread!topic/vertx/ZIpkBWYJtCc - i'm really keen to use your code generation in apiman's vert.x gateway

[12:17:55] <temporalfox> hi msavy sorry I haven't answered to you yet, I will answer in this thread soon

[12:18:34] <msavy> temporalfox: thank you very much, appreciate it!

[12:18:46] <temporalfox> msavy hold on

[12:19:07] <temporalfox> so you want to send buffers

[12:19:14] <temporalfox> I think we don't support vertx gen

[12:19:44] <temporalfox> becasue vertxgen does not understand Buffer natively

[12:20:06] <msavy> that's what i thought :-(. i was hoping you might have some alternative in @ProxyGen where you could generate an extra endpoint based upon the method name

[12:20:28] <temporalfox> I will think about something

[12:20:38] <temporalfox> actually that's purplefox_ that did the proxygen :-)

[12:20:58] <temporalfox> I did the rxjava gen

[12:21:02] <purplefox_> temporalfox: codegen does support buffer, the problem is with proxygen, as all proxy requests have to be serialized to json

[12:21:04] <temporalfox> I think the best way at the moment

[12:21:12] <temporalfox> might be to wrap it in json

[12:21:27] <msavy> in my existing implementations that's effectively what i do manually - let's say i have write(buffer), i have an additional endpoint “a.b.c.d.writeBuffer” which is purely for the buffer

[12:21:31] <msavy> no json whatsoever

[12:21:31] <temporalfox> I mean codegen does not support buffer as a native type

[12:21:37] <temporalfox> or byte[]

[12:21:45] <purplefox_> it does support buffer

[12:21:51] <temporalfox> yes

[12:22:01] <purplefox_> buffer is marked as @VertxGen

[12:22:05] <temporalfox> I mean that it does support it as any codegen

[12:22:09] <temporalfox> it does not have a special handling

[12:22:19] <temporalfox> for such case

[12:22:31] <purplefox_> the issue is with proxygen and json serialisation nothing to do with codegen

[12:22:35] <temporalfox> indeed

[12:22:37] <temporalfox> as you said

[12:23:10] <msavy> purplefox_: i guess i was also thinking of it from an efficiency perspective it'd be nice to do those separately so you don't do a load of json serialization/deserialization, right? special case where having an additional listener might be worth it?

[12:24:11] <msavy> i don't think it'd break the semantics of @ProxyGen, right?

[12:25:11] <purplefox_> sure. we serialize to json as that's the most interoperable (e.g. someone can easily call an endpoint by just sending messages) but alternative marshalling could be implemented

[12:27:14] <msavy> i was thinking that the other elements would still be JSON (in my example, 'head' and 'end' still arrive on the JSON channel), and only write(Buffer) is on its own 'binary only' channel.

[12:27:36] <msavy> i guess the alternative would be to use something like BSON, but i guess that'd still have more overhead than throwing the Buffer onto the wire

[12:28:42] <purplefox_> well.. you could encode the entire request as a single buffer and just send that. that would probably be most efficient

[12:48:37] <msavy> purplefox_: indeed, was just hoping to use temporalfox's proxy stuff as it's fantastic to have the annotated interfaces. i'll go and have a think :). thanks.

[12:57:13] <purplefox_> msavy: i know a little more about the proxy stuff as i wrote it, not temporalfox. but the idea of different marshalling has always been on the table

[12:57:21] <purplefox_> but you'd need to write a different template

[12:58:51] <purplefox_> maybe we could make the transcoder pluggable

[12:59:24] <purplefox_> then we could have different implementations - one that transcodes to json (i.e. the current one), another optimised one to buffer, etc

[13:04:10] <msavy> purplefox_: that's a cool idea

[13:52:52] <msavy> purplefox_: and i guess that could work on a hybrid basis, i.e. some of the methods in the same interface might use json, others might use some binary marshalling (or whatever)?

[13:53:07] <msavy> depending on what the optimal approach was

[13:53:11] <msavy> or do you think that's not practical

[14:46:06] <temporalfox> msavy the @ProxyGen interface could specify an encoder class, @ProxyGen(MyEncoder.class)

[14:49:50] <aesteve> hi everyone :)

[14:50:04] <aesteve> The Google Group is on fire lately :o

[14:56:26] <purplefox_> temporalfox: +1

[14:57:04] <purplefox_> aesteve: yes it's on fire, but a lot of the questions seem to be along the lines of “how do i set up a simple maven project” which is quite depressing

[14:58:43] <aesteve> some, yes but there are also real questions. Like “what happens when you call executeBlocking() from a worker thread”, which I actually never thought about

[14:59:17] <purplefox_> i don't understand that question and the way it's posted seems rather confused

[15:00:02] <purplefox_> i asked for clarification twice on that one

[15:00:44] <aesteve> I'm far from being a thread expert so i don't have a clue about the dealock thing

[15:01:09] <purplefox_> i've actually no idea what he is talking about

[15:01:20] <aesteve> but the question I'm asking myself is : what happens when you call executeBlocking from a worker verticle

[15:01:42] <aesteve> (because that doesn't seem right to me, but if you actually do so, what happens ?)

[15:01:42] <purplefox_> temporalfox: aesteve: anyway why are you two here? Isn't today when you celebrate breaking into a prison, then chopping off heads of kings or something ? ;)

[15:02:22] <aesteve> actually the Bastille day was really a symbol iirc my history lessons

[15:02:50] <aesteve> like they went into the Bastille, there was like 3 or 4 poor prisonners nobody knew about

[15:02:52] <purplefox_> but it's a national holiday, no?

[15:02:57] <aesteve> (and no guard)

[15:03:11] <aesteve> yes it's holiday :)

[15:03:24] <temporalfox> my wife and myself have been renovating a room of our apparement since saturday :-)

[15:03:31] <aesteve> but remember, vert.x isn't my job :)

[15:04:26] <aesteve> tough work with the current weather

[15:05:03] <purplefox_> brb

[15:07:33] <aesteve> purplefox_: for the question, the way I understand it is just : from a worker verticle, your code is already running in a thread from the worker pool, then if from this code you call executeBlocking, are you using another thread from the worker pool, or the same ?

[15:18:47] <purplefox_> aesteve: in a worker verticle there are no guarantees of which thread executes it

[15:19:05] <purplefox_> other than (in a standard worker) it's not executed by more than one thread concurrently

[15:19:56] <purplefox_> executeBlocking simply execcutes the block using a worker thread

[15:22:26] <purplefox_> msavy: temporalfox:

[15:22:45] <temporalfox> +1 purplefox_

[15:43:21] <msavy> purplefox_: temporalfox: thanks, guys!

[15:43:41] <DP2015> whats the differnece between vertx-mysql-postgresql-client, SQL common and JDBC client

[15:44:05] <DP2015> i want to connect to postgres?

[20:39:59] <jtruelove> yeah and i checked the code

[20:40:05] <jtruelove>

[20:40:12] <jtruelove> it is indeed the case

[20:40:19] <jtruelove> feels odd

[21:17:40] <AlexLehm> actually its documented like this

[21:19:01] <jtruelove> yeah that is the block of code i posted above

[21:19:31] <jtruelove> it's just odd to get the same behavior you have to create duplicate routes

[23:13:08] <voidDotClass>