SYSTEM AND METHOD FOR ENABLING REAL-TIME EVENTING
A method and system for real-time eventing including interacting with at least one configuration attribute according to instructions specified through an application programming interface (API); adding subscribers for an event channel; generating an event from operation of an application; publishing the event message to the event channel on an event router; processing the event message according to the at least one configuration attribute; identifying a subscriber to the event channel; and sending the event from the event router to the subscriber.
This application is a continuation of U.S. patent application Ser. No. 17/302,125, filed 23 APR. 2021, which is a continuation of U.S. patent application Ser. No. 16/361,925, filed 22 MAR. 2019, which is a continuation of U.S. patent application Ser. No. 15/936,670, filed 27 MAR. 2018, which is a continuation of U.S. patent application Ser. No. 14/452,277, filed 5 AUG. 2014, which is a continuation of U.S. patent application Ser. No. 13/170,056, filed 27 JUN. 2011, which claims the benefit of US Provisional Application Ser. No. 61/358,732, filed 25 JUN. 2010, the entirety of all of which are incorporated by reference herein.
TECHNICAL FIELDThis invention relates generally to the internet communication field, and more specifically to a new and useful system and method for enabling real-time eventing in the internet communication field.
BACKGROUNDFor many years, web developers and networked applications were limited to a client repeatedly polling a server with a request to receive updated information. In recent years, new mechanisms have been developed to allow a server to notify a client when new events occur. Pubsubhubbub, push notifications, and Comet are a few technologies that have enabled more of a publisher and subscriber relationship between networked clients. However, many publications require multiple publications that may depend on dynamic properties, and subscribers may have additional requirements such that simply receiving event messages from a publisher is unsatisfactory. Thus, there is a need in the internet communication field to create a new and useful system and method for enabling real-time eventing. This invention provides such a new and useful system and method.
The following description of the preferred embodiments of the invention is not intended to limit the invention to these preferred embodiments, but rather to enable any person skilled in the art to make and use this invention.
1. Method for Enabling Real-Time EventingAs shown in
As shown in
The method may additionally include receiving a subscriber generated client event, publishing the client event to the event router and identifying a call router subscribed to a client event, and sending the client event to the call router. These steps function to make the eventing method full duplex for two-way event publication and subscription. The duplex eventing system is substantially similar to the eventing system described, but where the client generates the events and the call router is subscribed to the events. The processing of events may occur for any suitable direction of event messaging.
The method of processing events S300 preferably functions to enhance the handling of an event message during distribution from a publisher to a subscriber. The method of processing events S300 preferably occurs within an event router and may have a number of variations. Method S300 preferably includes substeps of interacting with an configuration attribute S310. The method S300 additionally includes numerous variations of acting on configuration attributes including routing an event message S320, communicating event messages to an external application S330, and/or storing messages S340. Any additional form of processing of a configuration attribute may additionally be performed. Interacting with a configuration attribute and acting on a configuration attribute preferably function to allow functionality and processing of an event to be customizable and flexible for operators of an event. Processing of event messages can preferably be customized for each event with publishers and/or subscribers. This preferably centralized event distribution so publishers only need to publish to a single event that is customized for any suitable distribution setup.
As shown in
As shown in
As shown in
As shown in
As shown in
As shown in
The processing of an event message by an event router may be configured in a number of various ways. Preferably, the processing of an event is a fixed sequence of operations. Each type of processing (e.g., communicating with a delegate URI, routing, etc.) preferably is performed in a set sequence. This sequence may have numerous variations. As shown in
As shown in
An event router 210 of the preferred embodiment functions to maintain state of the publication and subscription (pub/sub) channel and manage distributing event messages. The subscriber 230 preferably registers a subscription to a particular event with the event router 210, and a publisher preferably 220 publishes content to a particular event channel on the event router 210. When the publisher publishes content in the form of an event message, the event router 210 preferably distributes the event message to all subscribers of the event. Preferably, the published event message is pushed to subscribers through an open HTTP connection (a single continuous HTTP connection). The open HTTP connection functions to simplify software of a web application using the system. Alternatively, the connection may push data with HTTPS, intermittent HTTP/HTTPS connections, AMF Channel, TCP connection, UDP connection, chat protocols such as jabber, or any suitable messaging framework. In one embodiment, as shown in
Additionally, the event router 210 preferably includes configuration attributes 212. Configuration attributes are preferably parameters of the event that may affect event behavior, manage subscribers and/or subscribers, and/or manage any suitable parameter of the event router 210. Configuration attributes 212 are preferably stateful resources stored within the event router 210 or alternatively accessible by the event router 210. The configuration attributes are preferably accessible through a representational state transfer (REST) application protocol interface (API). The event router additionally preferably includes an event message persistence 214, which functions as a record of event messages.
Configuration attributes 212 preferably function as readable or editable parameters that define functionality of event distribution. The configuration attributes 212 may be used as processing resources that impact event message processing. The configuration attributes are preferably RESTful resources in that the configuration attributes preferably have an associated URI that can receive HTTP messages. There is preferably a plurality of various configuration attributes that may be used with an event such as a route attribute, permissions attribute, a webhook attribute, a delegate URI attribute, or any suitable attribute. A route attribute preferably functions to define routing of an event message to additional events. A route may be defined to direct event messages to any suitable event or number of events. For example a route for event A may be defined so that event messages are additionally directed to event B. A permissions attribute may define security measures to control the publication and/or subscription of events. The permissions attribute may include security tokens that are used to validate subscribers or publishers. A webhook attribute preferably defines a URI that is sent a HTTP callback when an event message is received. The webhook URI functions to create even more flexibility in the sub/pub paradigm, where events can cause server actions through webhook mechanisms. A delegate URI attribute preferably defines a URI that is passed an event message prior to distributing the event message to subscribers. A delegate URI functions to enable outside processing of an event. The resource at the delegate URI is preferably a script or application that modifies the event message but may alternatively be reading the event message or using the event message in any suitable fashion. One example of a delegate URI may be a translation service that translates event messages to a different language prior to distribution to subscribers. There may additionally be a processing attribute or attributes that determine the ordering and configuration of the processes associated with the other configuration attributes. For example, an event may require an event message to be routed to a second event and then translated by a delegate URI (such that the second event does not receive the translated event message). While another event may require an event message to first be translated by a delegate URI and then routed. As an alternative, the configuration for processing an event may be set through a convention.
Message persistence 214 preferably functions to be an accessible record of past event messages. The message persistence is preferably a database of previous event messages. All event messages are preferably stored but event messages may alternatively be stored for certain amount of time or the message persistence 214 may store a particular number of event messages or particular portion of an event message. A record of event message may additionally store event message metadata as described below. The message persistence is preferably queryable.
The event router 210 preferably includes a configured order to the processing of an event message. In one preferred variation shown in
The publisher 220 of the preferred embodiment functions to create event messages for distribution. The publisher 220 may be any suitable networked device. The publisher may be a web server of a web application, a call router for telephony application, client device like a mobile phone, or any suitable networked device. The publisher is preferably registered with the event router 210 to know what events the publisher will be publishing. The publisher preferably creates an event message when the publisher 220 wants to notify subscribers of an event. The event message as described above preferably includes the event related message, which may include text, media, and/or any suitable data. The event message may additionally include event message metadata such as the category of the event message. The event message may additionally include a security token that functions to authenticate the identity of the publisher 220 and prevent others from posing as the publisher 220.
Event message metadata is preferably any suitable contextual data related to an event message. The event message metadata is preferably used by publishers 220, subscribers 230, and the event router 210 to more finely define functionality of event distribution. Event message metadata preferably describes message category, a tag, location information, time, author, mediatype, language, source, and/or any suitable metadata related to a particular event message. The metadata is preferably used for filtering event messages for a subscriber. For example, a subscriber may subscribe to an event called “news”, but only want to be notified of event messages that have the metadata event attribute of “tag=San Francisco”. Functionality of event attributes may additionally be conditionally enabled for event messages with particular metadata. Event routing, delegate URIs, and webhooks may only be used if metadata satisfy set conditions.
The subscriber 230 of the preferred embodiment functions to receive event messages from the event router 210. The subscriber preferably registers with the event router 210 to receive notifications of a particular event. The subscriber may additionally setup any suitable forms of filters for receiving event messages. Any suitable Boolean logic may be used with event messages and attributes to determine which event messages a subscriber 230 receives.
An alternative embodiment preferably implements the above methods in a computer-readable medium storing computer-readable instructions. The instructions are preferably executed by computer-executable components such as an event router. The computer-readable medium may be stored on any suitable computer readable media such as RAMs, ROMs, flash memory, EEPROMs, optical devices (CD or DVD), hard drives, floppy drives, or any suitable device. The computer-executable component is preferably a processor but the instructions may alternatively or additionally be executed by any suitable hardware device.
As a person skilled in the art will recognize from the previous detailed description and from the figures and claims, modifications and changes can be made to the preferred embodiments of the invention without departing from the scope of this invention defined in the following claims.
Claims
1. (canceled)
2. A system comprising:
- one or more computer processors;
- one or more computer memories;
- a set of instructions stored in the one or more computer memories, the set of instructions configuring the one or more computer processors to perform operations comprising: receiving a customization via an Application Programming Interface (API), the customization corresponding to a set of configuration attributes associated with a first event channel or a first subscriber, the customization specifying a second event channel or a second subscriber to which a first event message is to be routed; and in response to receiving the first event message, processing the first event message according to the customization corresponding to the set of configuration attributes, the processing including routing the first event message to the second event channel or the second subscriber.
3. The system of claim 2, the operations further comprising routing the first event message to user accounts included in a list of subscribers of the second event channel.
4. The system of claim 2, the operations further comprising sending the first event message to a client device associated with a user account as a result of the user account being included in a list of subscribers of the second event channel.
5. The system of claim 2, the operations further comprising, in response to receiving the first event message, identifying a set of subscribers that are subscribed to the first event channel, the set of subscribers including the first subscriber.
6. The system of claim 2, wherein the first event message is generated in response to a detection of an occurrence of a first type of event.
7. The system of claim 2, the operations further comprising receiving at least one routing attribute via the API, the routing attribute providing details pertaining to routing the first event message to user accounts included in a list of subscribers of the first event channel.
8. The system of claim 2, the operations further comprising, in response to the receiving of the first event message, not routing the first event message to the first event channel or the second subscriber.
9. A method comprising:
- receiving a customization via an Application Programming Interface (API), the customization corresponding to a set of configuration attributes associated with a first event channel or a first subscriber, the customization specifying a second event channel or a second subscriber to which a first event message is to be routed; and
- in response to receiving the first event message, processing the first event message according to the customization corresponding to the set of configuration attributes, the processing including routing the first event message to the second event channel or the second subscriber.
10. The method of claim 9, the operations further comprising routing the first event message to user accounts included in a list of subscribers of the second event channel.
11. The method of claim 9, the operations further comprising sending the first event message to a client device associated with a user account as a result of the user account being included in a list of subscribers of the second event channel.
12. The method of claim 9, the operations further comprising, in response to receiving the first event message, identifying a set of subscribers that are subscribed to the first event channel, the set of subscribers including the first subscriber.
13. The method of claim 9, wherein the first event message is generated in response to a detection of an occurrence of a first type of event.
14. The method of claim 9, the operations further comprising receiving at least one routing attribute via the API, the routing attribute providing details pertaining to routing the first event message to user accounts included in a list of subscribers of the first event channel.
15. The method of claim 9, the operations further comprising, in response to the receiving of the first event message, not routing the first event message to the first event channel or the second subscriber.
16. A non-transitory computer-readable storage medium storing a set of instructions that, when executed by one or more computer processors, causes the one or more computer processors to perform operations comprising:
- receiving a customization via an Application Programming Interface (API), the customization corresponding to a set of configuration attributes associated with a first event channel or a first subscriber, the customization specifying a second event channel or a second subscriber to which a first event message is to be routed; and
- in response to receiving the first event message, processing the first event message according to the customization corresponding to the set of configuration attributes, the processing including routing the first event message to the second event channel or the second subscriber.
17. The non-transitory computer-readable storage medium of claim 16, the operations further comprising routing the first event message to user accounts included in a list of subscribers of the second event channel.
18. The non-transitory computer-readable storage medium of claim 16, the operations further comprising sending the first event message to a client device associated with a user account as a result of the user account being included in a list of subscribers of the second event channel.
19. The non-transitory computer-readable storage medium of claim 16, the operations further comprising, in response to receiving the first event message, identifying a set of subscribers that are subscribed to the first event channel, the set of subscribers including the first subscriber,
20. The non-transitory computer-readable storage medium of claim 16, wherein the first event message is generated in response to a detection of an occurrence of a first type of event.
21. The non-transitory computer-readable storage medium of claim 16, the operations further comprising receiving at least one routing attribute via the API, the routing attribute providing details pertaining to routing the first event message to user accounts included in a list of subscribers of the first event channel.
Type: Application
Filed: Jun 29, 2021
Publication Date: Oct 21, 2021
Inventors: Jeffrey Lawson (San Francisco, CA), John Wolthuis (San Francisco, CA), Evan Cooke (San Francisco, CA), Jeffrey Comer (Mountain View, CA)
Application Number: 17/305,049