would at least
> > provide a method of sharing data that needs to be shared.
> >
> > Let me know if you have any thoughts on any of these changes
> >
> >
> > From: Enrico Olivelli
> > Sent: Tuesday, January 11, 2022 1:4
______
> From: Enrico Olivelli
> Sent: Tuesday, January 11, 2022 1:45 PM
> To: Dev
> Subject: Re: [DISCUSSION] PIP-133 Pulsar Functions Add API For Accessing
> Other Function States
>
> Thank you for posting your PIP !
>
> I am sharing some of Neng's concerns.
&g
ev
Subject: Re: [DISCUSSION] PIP-133 Pulsar Functions Add API For Accessing Other
Function States
Thank you for posting your PIP !
I am sharing some of Neng's concerns.
We should define clearly how security works.
Also, currently the function defines some "namespace" for the state
Thank you for posting your PIP !
I am sharing some of Neng's concerns.
We should define clearly how security works.
Also, currently the function defines some "namespace" for the state
storage, and we recently added support for custom state storage
implementation. With this change each function wi
Before we advance further, we first need to get on the same page of the
pros and cons of allowing this feature.
If functions can access (especially the write access) other functions'
state, the data ownership will be a mess, isolation is broken and data
security might be compromised.
On Wed,
Original PIP: https://github.com/apache/pulsar/issues/13633
Pasted below for quoting convenience.
-
## Motivation
Certain uses of Pulsar functions could benefit from the ability to access the
states of other functions. Currently functions can only access their own
states, and so sharing i
