Comet is a web application model in which a long-held HTTPS request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term, encompassing multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins. The Comet approach differs from the original model of the web, in which a browser requests a complete web page at a time. The use of Comet techniques in web development predates the use of the word Comet as a neologism for the collective techniques. Comet is known by several other names, including Ajax Push, Reverse Ajax, Two-way-web, HTTP Streaming, and HTTP server push among others. The term Comet is not an acronym, but was coined by Alex Russell in his 2006 blog post. In recent years, the standardisation and widespread support of WebSocket and Server-sent events has rendered the Comet model obsolete. == History == === Early Java applets === The ability to embed Java applets into browsers (starting with Netscape Navigator 2.0 in March 1996) made two-way sustained communications possible, using a raw TCP socket to communicate between the browser and the server. This socket can remain open as long as the browser is at the document hosting the applet. Event notifications can be sent in any format – text or binary – and decoded by the applet. === The first browser-to-browser communication framework === The very first application using browser-to-browser communications was Tango Interactive, implemented in 1996–98 at the Northeast Parallel Architectures Center (NPAC) at Syracuse University using DARPA funding. TANGO architecture has been patented by Syracuse University. TANGO framework has been extensively used as a distance education tool. The framework has been commercialized by CollabWorx and used in a dozen or so Command&Control and Training applications in the United States Department of Defense. === First Comet applications === The first set of Comet implementations dates back to 2000, with the Pushlets, Lightstreamer, and KnowNow projects. Pushlets, a framework created by Just van den Broecke, was one of the first open source implementations. Pushlets were based on server-side Java servlets, and a client-side JavaScript library. Bang Networks – a Silicon Valley start-up backed by Netscape co-founder Marc Andreessen – had a lavishly financed attempt to create a real-time push standard for the entire web. In April 2001, Chip Morningstar began developing a Java-based (J2SE) web server which used two HTTP sockets to keep open two communications channels between the custom HTTP server he designed and a client designed by Douglas Crockford; a functioning demo system existed as of June 2001. The server and client used a messaging format that the founders of State Software, Inc. assented to coin as JSON following Crockford's suggestion. The entire system, the client libraries, the messaging format known as JSON and the server, became the State Application Framework, parts of which were sold and used by Sun Microsystems, Amazon.com, EDS and Volkswagen. In March 2006, software engineer Alex Russell coined the term Comet in a post on his personal blog. The new term was a play on Ajax (Ajax and Comet both being common household cleaners in the USA). In 2006, some applications exposed those techniques to a wider audience: Meebo’s multi-protocol web-based chat application enabled users to connect to AOL, Yahoo, and Microsoft chat platforms through the browser; Google added web-based chat to Gmail; JotSpot, a startup since acquired by Google, built Comet-based real-time collaborative document editing. New Comet variants were created, such as the Java-based ICEfaces JSF framework (although they prefer the term "Ajax Push"). Others that had previously used Java-applet based transports switched instead to pure-JavaScript implementations. == Implementations == Comet applications attempt to eliminate the limitations of the page-by-page web model and traditional polling by offering two-way sustained interaction, using a persistent or long-lasting HTTP connection between the server and the client. Since browsers and proxies are not designed with server events in mind, several techniques to achieve this have been developed, each with different benefits and drawbacks. The biggest hurdle is the HTTP 1.1 specification, which states "this specification... encourages clients to be conservative when opening multiple connections". Therefore, holding one connection open for real-time events has a negative impact on browser usability: the browser may be blocked from sending a new request while waiting for the results of a previous request, e.g., a series of images. This can be worked around by creating a distinct hostname for real-time information, which is an alias for the same physical server. This strategy is an application of domain sharding. Specific methods of implementing Comet fall into two major categories: streaming and long polling. === Streaming === An application using streaming Comet opens a single persistent connection from the client browser to the server for all Comet events. These events are incrementally handled and interpreted on the client side every time the server sends a new event, with neither side closing the connection. Specific techniques for accomplishing streaming Comet include the following: ==== Hidden iframe ==== A basic technique for dynamic web application is to use a hidden iframe HTML element (an inline frame, which allows a website to embed one HTML document inside another). This invisible iframe is sent as a chunked block, which implicitly declares it as infinitely long (sometimes called "forever frame"). As events occur, the iframe is gradually filled with script tags, containing JavaScript to be executed in the browser. Because browsers render HTML pages incrementally, each script tag is executed as it is received. Some browsers require a specific minimum document size before parsing and execution is started, which can be obtained by initially sending 1–2 kB of padding spaces. One benefit of the iframes method is that it works in every common browser. Two downsides of this technique are the lack of a reliable error handling method, and the impossibility of tracking the state of the request calling process. ==== XMLHttpRequest ==== The XMLHttpRequest (XHR) object, a tool used by Ajax applications for browser–server communication, can also be pressed into service for server–browser Comet messaging by generating a custom data format for an XHR response, and parsing out each event using browser-side JavaScript; relying only on the browser firing the onreadystatechange callback each time it receives new data. === Ajax with long polling === None of the above streaming transports work across all modern browsers without negative side-effects. This forces Comet developers to implement several complex streaming transports, switching between them depending on the browser. Consequently, many Comet applications use long polling, which is easier to implement on the browser side, and works, at minimum, in every browser that supports XHR. As the name suggests, long polling requires the client to poll the server for an event (or set of events). The browser makes an Ajax-style request to the server, which is kept open until the server has new data to send to the browser, which is sent to the browser in a complete response. The browser initiates a new long polling request in order to obtain subsequent events. IETF RFC 6202 "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP" compares long polling and HTTP streaming. Specific technologies for accomplishing long-polling include the following: ==== XMLHttpRequest long polling ==== For the most part, XMLHttpRequest long polling works like any standard use of XHR. The browser makes an asynchronous request of the server, which may wait for data to be available before responding. The response can contain encoded data (typically XML or JSON) or Javascript to be executed by the client. At the end of the processing of the response, the browser creates and sends another XHR, to await the next event. Thus the browser always keeps a request outstanding with the server, to be answered as each event occurs. ==== Script tag long polling ==== While any Comet transport can be made to work across subdomains, none of the above transports can be used across different second-level domains (SLDs), due to browser security policies designed to prevent cross-site scripting attacks. That is, if the main web page is served from one SLD, and the Comet server is located at another SLD (which does not have cross-origin resource sharing enabled), Comet events cannot be used to modify the HTML and DOM of the main page, using those transports. This problem can be sidestepped by creating a proxy server in
Excalidraw
Excalidraw is an open-source, web-based virtual whiteboard and diagramming application. It is used to create diagrams, wireframes, and sketches within a web browser without requiring account registration. The software features a characteristic hand-drawn visual style and supports real-time multi-user collaboration using client-side end-to-end encryption. Excalidraw is released under the MIT License and is maintained by Excalidraw s.r.o., a company based in Brno, Czech Republic. == History == Excalidraw was created on 1 January 2020 by Christopher Chedeau, a software engineer at Meta Platforms. Chedeau, who previously co-created React Native and Prettier, initially developed the application as a personal project before registering the domain on 3 January 2020. Within its first months, the project attracted open-source contributors who assisted in expanding its features and rewriting the codebase into TypeScript and React. By early 2021, day-to-day operations moved to Czech developers David Luzar and Milos Vetesnik. In May 2021, the team incorporated Excalidraw s.r.o. in Brno and launched a commercial cloud-based version named Excalidraw+ to fund the open-source project's development. By May 2026, the main open-source repository on GitHub had accumulated over 123,000 stars. == Features and architecture == The application provides an infinite canvas for geometric shapes, lines, arrows, text, and freehand drawing. Its visual presentation relies on Rough.js, a JavaScript graphics library that alters standard vector paths to mimic irregular, hand-drawn lines. Excalidraw operates as a Progressive web application (PWA), allowing local installation and offline usage, saving data natively to local browser storage. Files use a native, JSON-based extension format (.excalidraw), and canvases can be exported to PNG or SVG formats. Real-time collaboration sessions are executed using Socket.IO via a relay server. Data transmission uses the browser's native Web Cryptography API to achieve end-to-end encryption. A symmetric AES key is generated on the client side and appended to the sharing URL as a fragment identifier (following the # character). Because web browsers do not transmit URL fragments to HTTP servers, the data remains unreadable to the distribution server. == Ecosystem == Excalidraw is distributed as an npm package, allowing third-party developers to embed the whiteboard component directly into external React web applications. Community-developed extensions integrate the application's file format into text editors and note-taking systems, including Visual Studio Code and Obsidian. The platform also has native integrations in commercial platforms such as Notion and HackerRank. == Reception == Google's developer relations team published a technical case study on Excalidraw as a reference implementation for Progressive Web Apps. The analysis highlighted the software's adoption of advanced web platform capabilities, specifically its utilization of the File System Access API and native Clipboard API to replicate desktop software behavior within a web browser environment.
FoundationDB
FoundationDB is a free and open-source multi-model distributed NoSQL database owned by Apple Inc. with a shared-nothing architecture. The product was designed around a "core" database, with additional features supplied in "layers." The core database exposes an ordered key–value store with transactions. The transactions are able to read or write multiple keys stored on any machine in the cluster while fully supporting ACID properties. Transactions are used to implement a variety of data models via layers. The FoundationDB Alpha program began in January 2012 and concluded on March 4, 2013, with their public Beta release. Their 1.0 version was released for general availability on August 20, 2013. On March 24, 2015, it was reported that Apple has acquired the company. A notice on the FoundationDB web site indicated that the company has "evolved" its mission and would no longer offer downloads of the software. On April 19, 2018, Apple open sourced the software, releasing it under the Apache 2.0 license. == Main features == The main features of FoundationDB include the following: Ordered key–value store In addition to supporting standard key-based reads and writes, the ordering property enables range reads that can efficiently scan large swaths of data. Transactions Transaction processing employs multiversion concurrency control for reads and optimistic concurrency for writes. Transactions can span multiple keys stored on multiple machines. ACID properties FoundationDB guarantees serializable isolation and strong durability via redundant storage on disk before transactions are considered committed. Layers Layers map new data models, APIs, and query languages to the FoundationDB core. They employ FoundationDB's ability to update multiple data elements in a single transaction, ensuring consistency. An example is their SQL layer. Commodity clusters FoundationDB is designed for deployment on distributed clusters of commodity hardware running Linux. Replication FoundationDB stores each piece of data on multiple machines according to a configurable replication factor. Triple replication is the recommended mode for clusters of 5 or more machines. Scalability FoundationDB is designed to support horizontal scaling through the addition of machines to a cluster while automatically handling data replication and partitioning. Systems supported FoundationDB supports packages for Linux, Windows, and macOS. The Linux version supports production clusters, while the Windows and macOS versions support local operation for development purposes. Configurations on Amazon EC2 are also supported. Programming language bindings FoundationDB supports language bindings for Python, Go, Ruby, Node.js, Java, PHP, and C, all of which are made available with the product. == Design limitations == The design of FoundationDB results in several limitations: Long transactions FoundationDB does not support transactions running over five seconds. Large transactions Transaction size cannot exceed 10 MB of total written keys and values. Large keys and values Keys cannot exceed 10 kB in size. Values cannot exceed 100 kB in size. == History == FoundationDB, headquartered in Vienna, Virginia, was started in 2009 by Nick Lavezzo, Dave Rosenthal, and Dave Scherer, drawing on their experience in executive and technology roles at their previous company, Visual Sciences. In March 2015 the FoundationDB Community site was updated to state that the company had changed directions and would no longer be offering downloads of its product. The company was acquired by Apple Inc., which was confirmed March 25, 2015. On April 19, 2018, Apple open sourced the software, releasing it under the Apache 2.0 license.
National Parking Platform
The National Parking Platform is a digital platform in the United Kingdom providing interoperability between car park operators, parking apps, and other service providers. It enables all parking apps that support the system: RingGo, JustPark, PayByPhone, Apcoa Connect, AppyParking, and Caura to work at all participating car parks. It has been rolled out in 13 local authorities so far. It was first developed by the Department for Transport starting in 2019, and since May 2025 is controlled by the British Parking Association on a not-for-profit basis. == Participating local authorities == Buckinghamshire Cheshire West and Chester Coventry City East Hertfordshire East Suffolk Liverpool City Manchester City Oxfordshire County Peterborough City Stevenage Sutton Walsall Welwyn Hatfield
Variable data publishing
Variable-data publishing (VDP) (also known as database publishing) is a term referring to the output of a variable composition system. While these systems can produce both electronically viewable and hard-copy (print) output, the "variable-data publishing" term today often distinguishes output destined for electronic viewing, rather than that which is destined for hard-copy print (e.g. variable data printing). Essentially the same techniques are employed to perform variable-data publishing, as those utilized with variable data printing. The difference is in the interpretation for output. While variable-data printing may be interpreted to produce various print streams or page-description files (e.g. AFP/IPDS, PostScript, PCL), variable-data publishing produces electronically viewable files, most commonly seen in the forms of PDF, HTML, or XML. Variable-data composition involves the use of data to conditionally: exhibit text (static blocks and/or variable content) exhibit images select fonts select colors format page layouts & flows Variable-data may be as simple as an address block or salutation. However, it can be any or all of the document's textual content—including words, sentences, paragraphs, pages, or the entire document. In other words, it can make up as little or as much of the document as the composer desires. Variable data may also be used to exhibit various images, such as logos, products, or membership photos. Further, variable-data can be used to build rule-based design schemes, including fonts, colors, and page formats. The possibilities are vast. The variable-data tools available today, make it possible to perform variable-data composition at nearly every stage of document production. However, the level of control that can be achieved varies, based upon how far into the document production process a variable-data tool is deployed. For example, if variable-data insertion occurs just prior to output...it's not likely that the text flow or layout can be altered with nearly as much control as would be available at the time of initial document composition. Many organizations will produce multiple forms of output (aka: multi-channel output), for the same document. This ensures that the published content is available to recipients via any form of access method they might require. When multi-channel output is utilized, integrity between those output channels often becomes important. Variable-data publishing may be performed on everything from a personal computer to a mainframe system. However, the speed and practical output volumes which can be achieved are directly affected by the computer power utilized. == Origin of the concept == The term variable-data publishing was likely an offshoot of the term "variable-data printing", first introduced to the printing industry by Frank Romano, Professor Emeritus, School of Print Media, at the College of Imaging Arts and Sciences at Rochester Institute of Technology. However, the concept of merging static document elements and variable document elements predates the term and has seen various implementations ranging from simple desktop 'mail merge', to complex mainframe applications in the financial and banking industry. In the past, the term VDP has been most closely associated with digital printing machines. However, in the past 3 years the application of this technology has spread to web pages, emails, and mobile messaging.
Wide-column store
A wide-column store (or extensible record store) is a type of NoSQL database. It uses tables, rows, and columns, but unlike a relational database, the names and format of the columns can vary from row to row in the same table. A wide-column store can be interpreted as a two-dimensional key–value store. Google's Bigtable is one of the prototypical examples of a wide-column store. == Wide-column stores versus columnar databases == Wide-column stores such as Bigtable and Apache Cassandra are not column stores in the original sense of the term, since their two-level structures do not use a columnar data layout. In genuine column stores, a columnar data layout is adopted such that each column is stored separately on disk. Wide-column stores do often support the notion of column families that are stored separately. However, each such column family typically contains multiple columns that are used together, similar to traditional relational database tables. Within a given column family, all data is stored in a row-by-row fashion, such that the columns for a given row are stored together, rather than each column being stored separately. Wide-column stores that support column families are also known as column family databases. == Notable examples == Notable wide-column stores include: Apache Accumulo Apache Cassandra Apache HBase Bigtable DataStax Enterprise (uses Apache Cassandra) DataStax Astra DB (uses Apache Cassandra) Hypertable Azure Tables ScyllaDB
Score bug
A score bug is a digital on-screen graphic which is displayed in a broadcast of a sporting event, displaying the current score and other statistics. It is similar in function to a scoreboard, and is usually placed at either the top or lower third of the television screen. == History == The concept of a persistent score bug was devised by Sky Sports head David Hill, who was dissatisfied over having to wait to see what the score was after tuning into a football match in-progress. The score bug was introduced when Sky launched its coverage of the then newly-formed English Premier League in August 1992. Hill's boss repeatedly demanded that the graphic be removed, describing it as the "stupidest thing [he] had ever seen". Hill defied the boss's demands and kept the graphic in place. ITV introduced a score bug at the start of the 1993–94 football season, and the BBC introduced a score bug towards the end of 1993. The concept was introduced to the United States by ABC Sports and ESPN during coverage of the 1994 FIFA World Cup. Their justification for the graphic was to provide a location for a rotating series of sponsor logos, in order to allow matches to air without commercial interruption. With the acquisition of rights to the National Football League (NFL) by BSkyB's American sibling Fox (a fellow venture of Rupert Murdoch), Hill became the first president of Fox Sports. Under Hill's leadership, Fox introduced a version of the score bug branded as the "Fox Box", which was part of its inaugural season of NFL coverage in 1994. Variety criticized it as an "annoying see-through clock and score graphic" and expressed concern for people "who actually watched the beginning of the game and would rather have their screen clear of graphics". Hill even received a death threat from an irate viewer, with a specific emphasis on him being a "foreigner", but the score bug soon became a ubiquitous feature for American football broadcasts, along with almost all American sports broadcasts in the years that followed. Dick Ebersol of NBC Sports initially opposed the idea of a score bug, as he thought that fans would dislike seeing more graphics on the screen and would change the channel from blowout games if the score was constantly being displayed. Since the 2010s, the on-air design and positioning of some score bugs have been influenced by the needs of Internet video (especially when viewing an event on devices with smaller screens), including bugs noticeably larger than prior iterations designed with television viewing in mind, or designs primarily kept towards the bottom-center of the screen (easing the ability for the bug to remain visible when highlights are cropped for square videos posted on social media). == Details == Score bugs used in team sports typically include the names of both teams, an abbreviation of the team's name, and/or the team's logo; for individual sports, they include the names of individual competitors. In sports where a game clock or playing periods are used, those are generally also displayed as part of the score bug. Some broadcasts also include teams' win-loss records. In 2024, ESPN experimented with adding a persistent win probability meter to its bug in Major League Baseball, which was based on input from its statisticians. === Variations === In addition to the above information, score bugs in some sports include additional information: In baseball, score bugs display the current inning, number of outs, the pitch clock if applicable, and a graphic displaying which bases are occupied; and usually include names of the current pitcher and batter, the pitcher's pitch count, and the number of balls and strikes accrued by the batter. In basketball, score bugs generally include the shot clock, the number of fouls accrued by each team, and whether a team is in the bonus. In cricket, score bugs often take the form of larger dashboards across the bottom of the screen, displaying the current team up and their number of runs, wickets, and overs, a display showing the runs scored and number of balls faced by the current batting partnership, and statistics for the opposing team's bowler (including the number of wickets scored and runs given up). In American football, score bugs usually include the play clock and the down and distance of the current play; they also incorporate graphics indicating when a penalty flag has been thrown. In ice hockey, score bugs display when a penalty or power play is in effect, and often include the number of shots on goal accrued by each team. In golf, Fox popularized the display of a persistent leaderboard graphic in the bottom-right of the screen, usually displaying the top 5. ==== Racing ==== Telecasts of automobile races often include a score bug with the current positions of participants, statistics such as distance behind the leader, and the remaining distance or number of laps. In the mid-2010s, NASCAR broadcasters such as Fox began to transition from horizontal tickers to vertical leaderboards (also referred to as "pylons", in reference to the physical scoring pylons at). The CW differentiated itself by using a horizontal display that divides the field into multiple columns along the bottom of the screen.