Hi, Lari.
Thanks for your proposal. Sounds good to me.
Supporting function pluggable essentially decouples the scheduling layer
and the computing layer. This can not only extend the function runtime in
more languages but even use this feature to implement a new non-function
runtime plugin, such a
On 2023/06/21 07:21:31 Asaf Mesika wrote:
> Lari, would it be possible to explain in more detail the paint points
> you're describing?
Well the point of the pluggable Function runtime types is to support other
technologies. Let's forget the reactive messaging solution for a moment.
With a plugga
On 2023/06/20 09:12:28 Enrico Olivelli wrote:
> > I am interested to know your thoughts on making the Pulsar Functions
> > runtime pluggable so that we can add new runtime types.
>
> I see that RuntimeFactory [1] is already customizable.
> What can we do more ?
> Are you talking about providing al
Lari, would it be possible to explain in more detail the paint points
you're describing?
You say processing messages individually is slow; hence, processing them in
batches is better. I guess it's especially useful if you need to group a
batch based on a key. What I don't understand is how the fra
Lari,
Il giorno mar 20 giu 2023 alle ore 09:33 Lari Hotari
ha scritto:
>
> Dear Pulsar Community Members,
>
> I would like to initiate a discussion on making the Pulsar Functions
> runtime "pluggable". In doing so, we can ensure that the addition of new
> runtime types becomes more straightforwar
Dear Pulsar Community Members,
I would like to initiate a discussion on making the Pulsar Functions
runtime "pluggable". In doing so, we can ensure that the addition of new
runtime types becomes more straightforward.
This use case will allow us to add support for Pulsar Functions based on
various
