[
https://issues.apache.org/jira/browse/SLING-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13852905#comment-13852905
]
Felix Meschberger commented on SLING-3292:
------------------------------------------
This sounds interesting.
Yet, we have to see how this may scale to not "block" the server with event
processing. Maybe we can buffer event transmission for a certain amount of
time, e.g. 0.5-3 seconds and then send the events as JSON arrays of JSON
arrarys of events.
Needs to be discussed whether we base on JCR Events or Sling Resource Events.
Reading the issue description I habe the impression to consider Sling Resource
Events.
> Web Hooks for Resource Observation
> ----------------------------------
>
> Key: SLING-3292
> URL: https://issues.apache.org/jira/browse/SLING-3292
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Lars Trieloff
> Priority: Minor
>
> I have an application that is storing resources for multiple other web
> applications and makes them available through the Sling REST API. Each of the
> consuming web applications has implemented their own caching and polling
> strategy for the resources made available by my Sling web application.
> In order to reduce latency when resources get updated in my Sling web
> application, and to reduce the need for polling resources on the side of my
> consuming web application, I would like to support Web Hooks
> (https://webhooks.pbworks.com/w/page/13385124/FrontPage - a pattern also
> supported by applications such as GitHub
> https://help.github.com/articles/post-receive-hooks or Evernote
> http://dev.evernote.com/doc/articles/polling_notification.php), so that
> client applications can register callbacks when one of the resources in my
> web application changes.
> The events to be observed should be:
> * resource added
> * resource moved
> * resource deleted
> * resource updated
> An observing application should be able to specify:
> * a pattern of resource paths it is interested in
> * a collection of resource types it is interested in
> * a collection of events it is interested in
> * a callback URL that should receive POST requests when a change matching the
> pattern above has been made
> The subsequent POST request should contain following information
> * timestamp of the change
> * URL of the changed resource
> * event type of the change
> * user initiating the change
> Furthermore, observing applications should be able to
> * create a new listener using a POST request
> * GET the list of listeners already registered
> * POST to update or delete an existing listener
> h5. Error Handling
> In case the registered callback URL is not available, Sling should retry the
> notification POST request, with increasing time between retries.
> After a maximum number of retries, the listener should be blacklisted, so
> that no further retries are being made
> h5. Configuration
> * maximum number of retries
> * enforce HTTPS (for production use)
> * authentication for outgoing requests
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
