[ https://issues.apache.org/jira/browse/CAMEL-13401?focusedWorklogId=226107&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-226107 ]
ASF GitHub Bot logged work on CAMEL-13401:
------------------------------------------
Author: ASF GitHub Bot
Created on: 11/Apr/19 16:04
Start Date: 11/Apr/19 16:04
Worklog Time Spent: 10m
Work Description: nicolaferraro commented on pull request #2867: CAMEL-13401: adding a webhook meta-component and first implementation with Telegram
URL: https://github.com/apache/camel/pull/2867
As per subject. This adds the capability for components to self register to receive push notifications instead of doing polling.
Registration is automatic by default, but it will be disabled in camel k where there will be a specific process to register webhooks.
In knative, components supporting webhooks can scale to 0 ;)
There are few things I'm not sure about... for example, the `MultiRestConsumer` class.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 226107)
Time Spent: 10m
Remaining Estimate: 0h
> Create a webhook meta-component
> -------------------------------
>
> Key: CAMEL-13401
> URL: https://issues.apache.org/jira/browse/CAMEL-13401
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Reporter: Nicola Ferraro
> Assignee: Nicola Ferraro
> Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The intention is to create a meta-component that allows other components to define how they can configure themselves to create push-based consumers by remotely configuring a webhook.
> The way it's used is similar to the master component.
>
> E.g.
> The following route starts from a Telegram polling consumer:
> {code:java}
> from("telegram:bots/token")
> .to("log:info"){code}
>
> By prepending the _webhook_ uri prefix, we literally _prepend a webhook listener_ to it:
> {code:java}
> from("webhook:telegram:bots/token")
> .to("log:info"){code}
>
> The role of the webhook meta-component is of:
> * Exposing one or more endpoints using the rest consumer factory
> * Running the delegate endpoint in webhook mode (each component defines the specific rules)
> * Registering the webhook at the webhook provider site (specific per component, external URL configurable)
> * Unregistering the webhook at the webhook provider site when it's no more necessary (specific per component)
> So, the meta-component sets up the infrastructure and orchestrates the workflow.
>
> Registration/deregistration should be configurable:
> * In standalone mode, the registration is done at route startup, the deregistration is done at route shutdown
> * In Camel K mode, automatic registration is disabled by default, because the deployment can be scale up/down (especially in Knative mode, where this happens automatically):
> ** Camel K will setup a webhook subscription resource that takes care of externally registering/deregistering the webhook when the integration is created/edited/deleted (will use the webhook component API for this)
>
> With this meta-component, in Camel K + Knative mode, we can create integrations from telegram, slack, github, twitter, dropbox, .... that can scale down to 0 when not used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)