Olio is a mobile app for sharing by giving away, getting, borrowing or lending things in your community for free, aiming to reduce household and food waste. It does this by connecting neighbours with spare food or household items to others nearby who wish to pick up those items. The food must be edible; it can be raw or cooked, sealed or open. Non-food items often listed on Olio include books, clothes and furniture. Those donating surplus food can be individuals or companies such as food retailers, restaurants, corporate canteens, food photographers etc., and donations can take place on an ad-hoc or recurrent basis. For example, some supermarket chains in the UK, including Tesco, the Midcounties Co-operative, Morrisons, Sainsbury's and Iceland have piloted Olio as an 'online food bank' to donate food and to reduce their waste. In March 2022, Olio partnered with Pandamart in Singapore. First launched in early 2015 by Tessa Clarke and Saasha Celestial-One, by October 2017 the company had raised $2.2 million in funding. Olio subsequently performed a series A funding round of $6 million in 2018 and a Series B of $43 million. Notable investors include Accel, Octopus Ventures and VNV Global. The Olio app had around 7 million registered users as of May 2023.
Hierarchical navigable small world
Hierarchical navigable small world (HNSW) is an algorithm for approximate nearest neighbor search. It is used to find items that are similar to a query item in a large collection, without comparing the query with every item one by one. The algorithm is commonly used for searching vector data. In these systems, an item such as a document, image, song, or user profile is represented by a list of numbers called a vector. Items with similar vectors are treated as similar according to the model that produced the vectors. HNSW provides a way to search these vectors quickly, especially in large datasets. HNSW stores vectors in a graph. Each vector is a node, and links connect it to some nearby vectors. The graph has several layers: upper layers contain fewer nodes and act like a rough map, while the bottom layer contains all nodes and gives a more detailed view. A search starts in an upper layer, follows links toward nodes that are closer to the query, and then repeats the process in lower layers until it finds a set of likely nearest neighbors. == Background == The nearest neighbor search problem asks which items in a dataset are closest to a query item. A direct search can compare the query with every item in the dataset, but this becomes slow when the dataset is large. Exact search methods based on spatial trees, such as the k-d tree and R-tree, can also become less effective for high-dimensional data, a problem often associated with the curse of dimensionality. Approximate nearest neighbor methods trade some exactness for speed or lower resource use. Instead of always guaranteeing the exact closest item, they try to return close items quickly. Other approximate methods include locality-sensitive hashing and product quantization. HNSW builds on research into small-world networks and navigable graphs. In a small-world graph, most nodes can be reached from other nodes through a short chain of links. In a navigable graph, a search procedure can use local information to move toward a target. Jon Kleinberg's work on navigation in small-world networks is an important example of this research area. Later work studied ways to add links that make graphs easier to navigate greedily. The HNSW algorithm extends earlier navigable small world methods for similarity search by adding a hierarchy of graph layers. This hierarchy helps the algorithm find a good region of the graph before doing a more detailed search in the bottom layer. == Algorithm == HNSW is based on a proximity graph. In this graph, nearby vectors are connected by edges. The algorithm uses these edges to move through the dataset, rather than scanning every vector. The graph is hierarchical. Every vector appears in the bottom layer. Some vectors are also placed in higher layers, with fewer vectors appearing as the layers go upward. The upper layers allow long-range movement across the dataset, while the lower layers allow a more detailed search near promising candidates. A typical search proceeds as follows: The search begins from an entry point in the highest layer. At each step, the algorithm looks at neighboring nodes and moves to a neighbor that is closer to the query. When it cannot find a closer neighbor in that layer, it moves down to the next layer. In the bottom layer, it explores a wider set of candidate nodes and returns the nearest candidates found. This search strategy is often described as greedy navigation. The algorithm repeatedly chooses locally better nodes, using the graph structure to approach the query point. == Construction and parameters == The HNSW graph is built incrementally. When a new vector is inserted, the algorithm assigns it a maximum layer, searches for nearby existing nodes, and connects the new node to selected neighbors in each layer where it appears. Implementations usually expose parameters that control the trade-off between speed, accuracy, memory use, and construction time. A higher number of graph connections can improve recall but requires more memory. A larger search candidate list can improve accuracy but makes queries slower. A larger construction candidate list can improve the quality of the graph but makes index building slower. Because HNSW is approximate, its results are not always identical to a full exact search. Its practical performance depends on the dataset, distance measure, implementation, and parameter settings. Benchmarking studies have found HNSW-based libraries to be strong performers among approximate nearest neighbor methods, although worst-case performance can differ from performance on common benchmark datasets. == Use in vector search systems == HNSW is used as an index in systems that store and search high-dimensional vectors. These systems include vector databases, search engines, and database extensions. Typical uses include semantic search, recommender systems, image similarity search, and retrieval-augmented generation. Several software projects implement or support HNSW. Libraries include hnswlib, which is associated with the original HNSW authors, and FAISS. Database and search systems that document HNSW support include Apache Lucene, Chroma, ClickHouse, DuckDB, MariaDB, Milvus, pgvector, Qdrant, and Redis.
Single address space operating system
In computer science, a single address space operating system (or SASOS) is an operating system that provides only one globally shared address space for all processes. In a single address space operating system, numerically identical (virtual memory) logical addresses in different processes all refer to exactly the same byte of data. In a traditional OS with private per-process address space, memory protection is based on address space boundaries ("address space isolation"). Single address-space operating systems make translation and protection orthogonal, which in no way weakens protection. The core advantage is that pointers (i.e. memory references) have global validity, meaning their meaning is independent of the process using it. This allows sharing pointer-connected data structures across processes, and making them persistent, i.e. storing them on backup store. Some processor architectures have direct support for protection independent of translation. On such architectures, a SASOS may be able to perform context switches faster than a traditional OS. Such architectures include Itanium, and Version 5 of the Arm architecture, as well as capability architectures such as CHERI. A SASOS should not be confused with a flat memory model, which provides no address translation and generally no memory protection. In contrast, a SASOS makes protection orthogonal to translation: it may be possible to name a data item (i.e. know its virtual address) while not being able to access it. SASOS projects using hardware-based protection include the following: Angel IBM i (formerly called OS/400) Iguana at NICTA, Australia Mungi at NICTA, Australia Nemesis Opal Scout Sombrero Related are OSes that provide protection through language-level type safety: Br1X Genera JX a research Java OS Phantom OS Singularity Theseus OS Torsion
Virtual DOM
A virtual DOM is a lightweight JavaScript representation of the Document Object Model (DOM) used in declarative web frameworks such as React, Vue.js, and Elm. Since generating a virtual DOM is relatively fast, any given framework is free to rerender the virtual DOM as many times as needed relatively cheaply. The framework can then find the differences between the previous virtual DOM and the current one (diffing), and only makes the necessary changes to the actual DOM (reconciliation). While technically slower than using just vanilla JavaScript, the pattern makes it much easier to write websites with a lot of dynamic content, since markup is directly coupled with state. Similar techniques include Ember.js' Glimmer and Angular's incremental DOM. == History == The JavaScript DOM API has historically been inconsistent across browsers, clunky to use, and difficult to scale for large projects. While libraries like jQuery aimed to improve the overall consistency and ergonomics of interacting with HTML, it too was prone to repetitive code that didn't describe the nature of the changes being made well and decoupled logic from markup. The release of AngularJS in 2010 provided a major paradigm shift in the interaction between JavaScript and HTML with the idea of dirty checking. Instead of imperatively declaring and destroying event listeners and modifying individual DOM nodes, changes in variables were tracked and sections of the DOM were invalidated and rerendered when a variable in their scope changed. This digest cycle provided a framework to write more declarative code that coupled logic and markup in a more logical way. While AngularJS aimed to provide a more declarative experience, it still required data to be explicitly bound to and watched by the DOM, and performance concerns were cited over the expensive process of dirty checking hundreds of variables. To alleviate these issues, React was the first major library to adopt a virtual DOM in 2013, which removed both the performance bottlenecks (since diffing and reconciling the DOM was relatively cheap) and the difficulty of binding data (since components were effectively just objects). Other benefits of a virtual DOM included improved security since XSS was effectively impossible and better extensibility since a component's state was entirely encapsulated. Its release also came with the advent of JSX, which further coupled HTML and JavaScript with an XML-like syntax extension. Following React's success, many other web frameworks copied the general idea of an ideal DOM representation in memory, such as Vue.js in 2014, which used a template compiler instead of JSX and had fine-grained reactivity built as part of the framework. In recent times, the virtual DOM has been criticized for being slow due to the additional time required for diffing and reconciling DOM nodes. This has led to the development of frameworks without a virtual DOM, such as Svelte, and frameworks that edit the DOM in-place such as Angular 2. == Implementations == === React === React pioneered the use of a virtual DOM to make components declaratively. Virtual DOM nodes are constructed using the createElement() function, but are often transpiled from JSX to make writing components more ergonomic. In class-based React, virtual DOM nodes are returned from the render() function, while in functional hook-based components, the return value of the function itself serves as the page markup. === Vue.js === Vue.js uses a virtual DOM to handle state changes, but is usually not directly interacted with; instead, a compiler is used to transform HTML templates into virtual DOM nodes as an implementation detail. While Vue supports writing JSX and custom render functions, it's more typical to use the template compiler since a build step isn't required that way. === Svelte === Svelte does not have a virtual DOM, with its creator Rich Harris calling the virtual DOM "pure overhead". Instead of diffing and reconciling DOM nodes at runtime, Svelte uses compile-time reactivity to analyze markup and generate JavaScript code that directly manipulates the DOM, drastically increasing performance.
ISO/IEC 11801
International standard ISO/IEC 11801 Information technology — Generic cabling for customer premises specifies general-purpose telecommunication cabling systems (structured cabling) that are suitable for a wide range of applications (analog and ISDN telephony, various data communication standards, building control systems, factory automation). It is published by ISO/IEC JTC 1/SC 25/WG 3 of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). It covers both balanced copper cabling and optical fibre cabling. The standard was designed for use within commercial premises that may consist of either a single building or of multiple buildings on a campus. It was optimized for premises that span up to 3 km, up to 1 km2 office space, with between 50 and 50,000 persons, but can also be applied for installations outside this range. A major revision was released in November 2017, unifying requirements for commercial, home and industrial networks. == Classes and categories == The standard defines several link/channel classes and cabling categories of twisted-pair copper interconnects, which differ in the maximum frequency for which a certain channel performance is required: Class A: Up to 100 kHz using Category 1 cable and connectors Class B: Up to 1 MHz using Category 2 cable and connectors Class C: Up to 16 MHz using Category 3 cable and connectors Class D: Up to 100 MHz using Category 5e cable and connectors Class E: Up to 250 MHz using Category 6 cable and connectors Class EA: Up to 500 MHz using category 6A cable and connectors (Amendments 1 and 2 to ISO/IEC 11801, 2nd Ed.) Class F: Up to 600 MHz using Category 7 cable and connectors Class FA: Up to 1 GHz (1000 MHz) using Category 7A cable and connectors (Amendments 1 and 2 to ISO/IEC 11801, 2nd Ed.) Class BCT-B: Up to 1 GHz (1000 MHz) using with coaxial cabling for BCT applications. (ISO/IEC 11801-1, Edition 1.0 2017-11) Class I: Up to 2 GHz (2000 MHz) using Category 8.1 cable and connectors (ISO/IEC 11801-1, Edition 1.0 2017-11) Class II: Up to 2 GHz (2000 MHz) using Category 8.2 cable and connectors (ISO/IEC 11801-1, Edition 1.0 2017-11) The standard link impedance is 100 Ω. (The older 1995 version of the standard also permitted 120 Ω and 150 Ω in Classes A−C, but this was removed from the 2002 edition.) The standard defines several classes of optical fiber interconnect: OM1: Multimode, 62.5 μm core; minimum modal bandwidth of 200 MHz·km at 850 nm OM2: Multimode, 50 μm core; minimum modal bandwidth of 500 MHz·km at 850 nm OM3: Multimode, 50 μm core; minimum modal bandwidth of 2000 MHz·km at 850 nm OM4: Multimode, 50 μm core; minimum modal bandwidth of 4700 MHz·km at 850 nm OM5: Multimode, 50 μm core; minimum modal bandwidth of 4700 MHz·km at 850 nm and 2470 MHz·km at 953 nm OS1: Single-mode, maximum attenuation 1 dB/km at 1310 and 1550 nm OS1a: Single-mode, maximum attenuation 1 dB/km at 1310, 1383, and 1550 nm OS2: Single-mode, maximum attenuation 0.4 dB/km at 1310, 1383, and 1550 nm Grandfathered === OM5 === OM5 fiber is designed for wideband applications using SWDM multiplexing of 4–16 carriers (40G=4λ×10G, 100G=4λ×25G, 400G=4×4λ×25G) in the 850–953 nm range. === Category 7 === Class F channel and Category 7 cable are backward compatible with Class D/Category 5e and Class E/Category 6. Class F features even stricter specifications for crosstalk and system noise than Class E. To achieve this, shielding was added for individual wire pairs and the cable as a whole. Unshielded cables rely on the quality of the twists to protect from EMI. This involves a tight twist and carefully controlled design. Cables with individual shielding per pair such as Category 7 rely mostly on the shield and therefore have pairs with longer twists. The Category 7 cable standard was ratified in 2002, and primarily introduced to support 10 gigabit Ethernet over 100 m of copper cabling. Like the earlier standards, it contains four twisted copper wire pairs rated for transmission frequencies of up to 600 MHz. However, in 2006, Category 6A was ratified for Ethernet to allow 10 Gbit/s while still using the conventional 8P8C connector. Care is required to avoid signal degradation by mixing cable and connectors not designed for that use, however similar. Most manufacturers of active equipment and network cards have chosen to support the 8P8C for their 10 gigabit Ethernet products on copper and not GG45, ARJ45, or TERA connectors as Class F would have originally called for. Therefore, the Category 6 specification was revised to Category 6A to permit this use; products therefore require a Class EA channel (ie, Cat 6A). As of 2019, some equipment has been introduced which has connectors supporting the Class F (Category 7) channel. Note, however, that Category 7 is not recognized by the TIA/EIA. === Category 7A === Class FA (Class F Augmented) channels and Category 7A cables, introduced by ISO 11801 Edition 2 Amendment 2 (2010), are defined at frequencies up to 1000 MHz. The intent of the Class FA was to possibly support the future 40 gigabit Ethernet: 40GBASE-T. Simulation results have shown that 40 gigabit Ethernet may be possible at 50 meters and 100 gigabit Ethernet at 15 meters. In 2007, researchers at Pennsylvania State University predicted that either 32 nm or 22 nm circuits would allow for 100 gigabit Ethernet at 100 meters. However, in 2016, the IEEE 802.3bq working group ratified the amendment 3 which defines 25GBASE-T and 40GBASE-T on Category 8 cabling specified to 2000 MHz. The Class FA therefore does not support 40G Ethernet. As of 2025, there is no equipment that has connectors supporting the Class FA (Category 7A) channel. Category 7A is not recognized in TIA/EIA. === Category 8 === Category 8 was ratified by the TR43 working group under ANSI/TIA 568-C.2-1. It is defined up to 2000 MHz and only for distances up to 30 m or 36 m, depending on the patch cords used. ISO/IEC JTC 1/SC 25/WG 3 developed the equivalent standard ISO/IEC 11801-1:2017/COR 1:2018, with two options: Class I channel (Category 8.1 cable): minimum cable design U/FTP or F/UTP, fully backward compatible and interoperable with Class EA (Category 6A) using 8P8C connectors; Class II channel (Category 8.2 cable): F/FTP or S/FTP minimum, interoperable with Class FA (Category 7A) using TERA or GG45. == Abbreviations for twisted pairs == Annex E, Acronyms for balanced cables, provides a system to specify the exact construction for both unshielded and shielded balanced twisted pair cables. It uses three letters—U for unshielded, S for braided shielding, and F for foil shielding—to form a two-part abbreviation in the form of xx/xTP, where the first part specifies the type of overall cable shielding, and the second part specifies shielding for individual cable elements. Common cable types include U/UTP (unshielded cable); U/FTP (individual pair shielding without the overall screen); F/UTP, S/UTP, or SF/UTP (overall screen without individual shielding); and F/FTP, S/FTP, or SF/FTP (overall screen with individual foil shielding). == 2017 edition == In November 2017, a new edition was released by ISO/IEC JTC 1/SC 25 "Interconnection of information technology equipment" subcommittee. It is a major revision of the standard which has unified several prior standards for commercial, home, and industrial networks, as well as data centers, and defines requirements for generic cabling and distributed building networks. The new series of standards replaces the former 11801 standard and includes six parts: == Versions == ISO/IEC 11801:1995 (Ed. 1) ISO/IEC 11801:2000 (Ed. 1.1) – Edition 1, Amendment 1 ISO/IEC 11801:2002 (Ed. 2) ISO/IEC 11801:2008 (Ed. 2.1) – Edition 2, Amendment 1 ISO/IEC 11801:2010 (Ed. 2.2) – Edition 2, Amendment 2 ISO/IEC 11801-1:2017, -1:2017/Cor 1:2018, -2:2017, -3:2017, -3:2017/Amd 1:2021, -3:2017/Cor 1:2018, -4:2017, -4:2017/Cor 1:2018, -5:2017, -5:2017/Cor 1:2018, -6:2017, -6:2017/Cor 1:2018 (As of September 2023, this set is current.)
Collision detection
Collision detection is the computational problem of detecting an intersection of two or more objects in virtual space. More precisely, it deals with the questions of if, when, and where two or more objects intersect. Collision detection is a classic problem of computational geometry with applications in computer graphics, physical simulation, video games, robotics (including autonomous driving), and computational physics. Collision detection algorithms can be divided into operating on 2D or 3D spatial objects. == Overview == Collision detection is closely linked to calculating the distance between objects, as objects collide when the distance between them is less than or equal to zero. Negative distances indicate that one object has penetrated another. Performing collision detection requires more context than just the distance between the objects. Accurately identifying the points of contact on both objects' surfaces is also essential for computing a physically accurate collision response. The complexity of this task increases with the level of detail in the objects' representations: the more intricate the model, the greater the computational cost. Collision detection frequently involves dynamic objects, adding a temporal dimension to distance calculations. Instead of simply measuring distance between static objects, collision detection algorithms often aim to determine whether the objects' motion will bring them to a point in time when their distance is zero—an operation that adds significant computational overhead. In collision detection involving multiple objects, a naive approach would require detecting collisions for all pairwise combinations of objects. As the number of objects increases, the number of required comparisons grows rapidly: for n {\displaystyle n} objects, n ( n − 1 ) / 2 {n(n-1)}/{2} intersection tests are needed with a naive approach. This quadratic growth makes such an approach computationally expensive as n {\displaystyle n} increases. Due to the complexity mentioned above, collision detection is a computationally intensive process. Nevertheless, it is essential for interactive applications like video games, robotics, and real-time physics engines. To manage these computational demands, extensive efforts have gone into optimizing collision detection algorithms. A commonly used approach towards accelerating the required computations is to divide the process into two phases: the broad phase and the narrow phase. The broad phase aims to answer the question of whether objects might collide, using a conservative but efficient approach to rule out pairs that clearly do not intersect, thus avoiding unnecessary calculations. Objects that cannot be definitively separated in the broad phase are passed to the narrow phase. Here, more precise algorithms determine whether these objects actually intersect. If they do, the narrow phase often calculates the exact time and location of the intersection. == Broad phase == This phase aims at quickly finding objects or parts of objects for which it can be quickly determined that no further collision test is needed. A useful property of such approach is that it is output sensitive. In the context of collision detection this means that the time complexity of the collision detection is proportional to the number of objects that are close to each other. An early example of that is the I-COLLIDE where the number of required narrow phase collision tests was O ( n + m ) {\displaystyle O(n+m)} where n {\displaystyle n} is the number of objects and m {\displaystyle m} is the number of objects at close proximity. This is a significant improvement over the quadratic complexity of the naive approach. === Spatial partitioning === Several approaches can be grouped under the spatial partitioning umbrella, which includes octrees (for 3D), quadtrees (for 2D), binary space partitioning (or BSP trees) and other, similar approaches. If one splits space into a number of simple cells, and if two objects can be shown not to be in the same cell, then they need not be checked for intersection. Dynamic scenes and deformable objects require updating the partitioning which can add overhead. === Bounding volume hierarchy === Bounding Volume Hierarchy (BVH) is a tree structure over a set of bounding volumes. Collision is determined by doing a tree traversal starting from the root. If the bounding volume of the root doesn't intersect with the object of interest, the traversal can be stopped. If, however there is an intersection, the traversal proceeds and checks the branches for each there is an intersection. Branches for which there is no intersection with the bounding volume can be culled from further intersection test. Therefore, multiple objects can be determined to not intersect at once. BVH can be used with deformable objects such as cloth or soft-bodies but the volume hierarchy has to be adjusted as the shape deforms. For deformable objects we need to be concerned about self-collisions or self intersections. BVH can be used for that end as well. Collision between two objects is computed by computing intersection between the bounding volumes of the root of the tree as there are collision we dive into the sub-trees that intersect. Exact collisions between the actual objects, or its parts (often triangles of a triangle mesh) need to be computed only between intersecting leaves. The same approach works for pair wise collision and self-collisions. === Exploiting temporal coherence === During the broad-phase, when the objects in the world move or deform, the data-structures used to cull collisions have to be updated. In cases where the changes between two frames or time-steps are small and the objects can be approximated well with axis-aligned bounding boxes, the sweep and prune algorithm can be a suitable approach. Several key observation make the implementation efficient: Two bounding-boxes intersect if, and only if, there is overlap along all three axes; overlap can be determined, for each axis separately, by sorting the intervals for all the boxes; and lastly, between two frames updates are typically small (making sorting algorithms optimized for almost-sorted lists suitable for this application). The algorithm keeps track of currently intersecting boxes, and as objects move, re-sorting the intervals helps keep track of the status. === Pairwise pruning === Once a pair of physical bodies has been selected for further investigation, collisions need to be checked more carefully. However, in many applications, individual objects (if they are not too deformable) are described by a set of smaller primitives, mainly triangles. So there are two sets of triangles, S = S 1 , S 2 , … , S n {\displaystyle S={S_{1},S_{2},\dots ,S_{n}}} and T = T 1 , T 2 , … , T n {\displaystyle T={T_{1},T_{2},\dots ,T_{n}}} (for simplicity, each set has the same number of triangles.) The obvious thing to do is to check all triangles S j {\displaystyle S_{j}} against all triangles T k {\displaystyle T_{k}} for collisions, but this involves n 2 {\displaystyle n^{2}} comparisons, which is highly inefficient. If possible, it is desirable to use a pruning algorithm to reduce the number of pairs of triangles that need to be checked. The most widely used family of algorithms is known as the hierarchical bounding volumes method. As a preprocessing step, for each object (e.g., S {\displaystyle S} and T {\displaystyle T} ) calculates a hierarchy of bounding volumes. Then, at each time step, when collisions need to be checked between S {\displaystyle S} and T {\displaystyle T} , the hierarchical bounding volumes are used to reduce the number of pairs of triangles under consideration. For simplicity, provide an example using bounding spheres, although it has been noted that spheres are undesirable in many cases. If E {\displaystyle E} is a set of triangles, a bounding sphere is pre-calculated. B ( E ) {\displaystyle B(E)} . There are many ways of choosing B ( E ) {\displaystyle B(E)} , B ( E ) {\displaystyle B(E)} is a sphere that completely contains E {\displaystyle E} and is as small as possible. Ahead of time, B ( S ) {\displaystyle B(S)} and B ( T ) {\displaystyle B(T)} can be computed. Clearly, if these two spheres do not intersect (and that is very easy to test), then neither do S {\displaystyle S} and T {\displaystyle T} . This is not much better than an n-body pruning algorithm, however. If E = E 1 , E 2 , … , E m {\displaystyle E={E_{1},E_{2},\dots ,E_{m}}} is a set of triangles, then split it into two halves L ( E ) := E 1 , E 2 , … , E m / 2 {\displaystyle L(E):={E_{1},E_{2},\dots ,E_{m/2}}} and R ( E ) := E m / 2 + 1 , … , E m − 1 , E m {\displaystyle R(E):={E_{m/2+1},\dots ,E_{m-1},E_{m}}} . Apply this to S {\displaystyle S} and T {\displaystyle T} , and calculate (ahead of time) the bounding spheres B ( L ( S ) ) , B ( R ( S ) ) {\displaystyle B(L(S)),B(R(S))} and B ( L ( T ) ) , B ( R ( T ) ) {\displaystyle B(L(T)),B(R(T))} . T
Pull technology
Pull coding or client pull is a style of network communication, where the initial request for data originates from the client, and then is responded to by the server. The reverse is known as push technology, where the server pushes data to clients. Pull requests form the foundation of network computing, where many clients request data from centralized servers. Pull is used extensively on the Internet for HTTP page requests from websites. A push can also be simulated using multiple pulls within a short amount of time. For example, when pulling POP3 email messages from a server, a client can make regular pull requests, every few minutes. To the user, the email then appears to be pushed, as emails appear to arrive close to real-time. A trade-off of this system is that it places a heavier load on both the server and network to function correctly. Many web feeds, such as RSS are technically pulled by the client. With RSS, the user's RSS reader polls the server periodically for new content; the server does not send information to the client unrequested. This continual polling is inefficient and has contributed to the shutdown or reduction of several popular RSS feeds that could not handle the bandwidth. For solving this problem, the WebSub protocol, as another example of a push code, was devised. Podcasting is specifically a pull technology. When a new podcast episode is published to an RSS feed, it sits on the server until it is requested by a feed reader, mobile podcasting app, or directory. Directories such as Apple Podcasts (iTunes), The Blubrry Directory, and many apps' directories request the RSS feed periodically to update the Podcast's listing on those platforms. Subscribers to those RSS feeds via app or reader will get the episodes when they request the RSS feed next time, independent of when the directory listing updates.