Thanks for starting this discussion! Definitely a current gap not having
well-established SPI delineations.
As a starting point, certainly any of the runtime-configurable
factory/supplier types demonstrate intent for service-provider
extensibility achievable without modifying any Polaris code dire
+1
Licenses look consistent with the last set of tarball binary releases. I
wasn't able to test the build without docker, which is annoying. Otherwise
looks good to me.
On Thu, Aug 14, 2025 at 1:24 PM Dmitri Bourlatchkov
wrote:
> +1 (nb)
>
> Cheers,
> Dmitri.
>
> On Wed, Jul 30, 2025 at 3:51 AM
Hi Dennis,
This may be quite off topic here, so I'll keep it short. I'm open to
discussing this matter in a dedicated thread :)
My reading is that CallContext is effectively an alternative to CDI.
However, CDI is richer in functionality. Not all requests / calls have the
same set of contextual da
Thanks Robert, Alex for working on this. Thanks Prashant for chiming in.
This is a big feature deserving a design doc and community discussion. Can
we have a design doc first?
Yufei
On Thu, Aug 14, 2025 at 8:53 AM Alexandre Dutra wrote:
> Hi all,
>
> I've drafted an initial version of remote s
To summarize a bit:
I agreed that the task context should be treated differently from both call
context and realm context. We should design the task context explicitly,
and it will inevitably need to be serialized so that other nodes can
execute the task with enough context.
When designing it, we
+1 (nb)
Cheers,
Dmitri.
On Wed, Jul 30, 2025 at 3:51 AM Jean-Baptiste Onofré
wrote:
> Hi everyone,
>
> The Apache Polaris community has voted and approved the release of
> Apache Polaris 1.0.1-incubating (rc0). We now kindly request the IPMC
> members to review and vote for this release.
>
> Po
Hi all,
I've drafted an initial version of remote signing enablement in
Polaris [1]. Your comments are welcome, either here or directly on the
PR, where there's already some valuable discussion.
This PR aims to be a minimum viable product for remote signing, not a
comprehensive implementation. No
IMHO encoding stuff in the url so that we can avoid reverse lookup is the
right thing to do !
Since we are relying on this, signing by a key that the catalog owns seems
a logical natural step to avoid tampering.
Nevertheless it's a standard practice which S3 has that gives you signature
in the pre-
Discussion here is fine but formal approval is from PPMC.
Le jeu. 14 août 2025 à 06:45, Jean-Baptiste Onofré a
écrit :
> Hi
>
> I’m ok with that.
>
> However, just a note : a message should have been sent to private mailing
> list first for approval from the PPMC.
> Also we have to follow
>
> ht
Hi
I’m ok with that.
However, just a note : a message should have been sent to private mailing
list first for approval from the PPMC.
Also we have to follow
https://incubator.apache.org/guides/publicity.html#2_during_the_incubation_process
and
https://incubator.apache.org/guides/branding.html.
I think the discussion has deviated quite a bit.
For posterity, the only use case in Polaris for the only call site of
`.copy()` is "purge table data". All that needs is the information
about "what shall be purged" and during execution a way to get access
to the object storage.
Any task execution
11 matches
Mail list logo
