[ 
https://issues.apache.org/jira/browse/CAMEL-13401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16813216#comment-16813216
 ] 

Willem Jiang commented on CAMEL-13401:
--------------------------------------

[~nferraro] I just have a quick question for it.  How do we store the metadata 
information?
We can use webhook to track the change of metadata, but what if there is no 
instance of telegram endpoint,  is there still a webhook could help us handle 
to change of the telegram endpoint metadata.

> 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
>
>
> 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)

Reply via email to