HTTP compression is a capability that can be built into web servers and web clients to improve transfer speed and bandwidth utilization. HTTP data is compressed before it is sent from the server: compliant browsers will announce what methods are supported to the server before downloading the correct format; browsers that do not support compliant compression method will download uncompressed data. The most common compression schemes include gzip and Brotli; a full list of available schemes is maintained by the IANA. There are two different ways compression can be done in HTTP. At a lower level, a Transfer-Encoding header field may indicate the payload of an HTTP message is compressed. At a higher level, a Content-Encoding header field may indicate that a resource being transferred, cached, or otherwise referenced is compressed. Compression using Content-Encoding is more widely supported than Transfer-Encoding, and some browsers do not advertise support for Transfer-Encoding compression to avoid triggering bugs in servers. == Compression scheme negotiation == The negotiation is done in two steps, described in RFC 2616 and RFC 9110: 1. The web client advertises which compression schemes it supports by including a list of tokens in the HTTP request. For Content-Encoding, the list is in a field called Accept-Encoding; for Transfer-Encoding, the field is called TE. 2. If the server supports one or more compression schemes, the outgoing data may be compressed by one or more methods supported by both parties. If this is the case, the server will add a Content-Encoding or Transfer-Encoding field in the HTTP response with the used schemes, separated by commas. The web server is by no means obligated to use any compression method – this depends on the internal settings of the web server and also may depend on the internal architecture of the website in question. == Content-Encoding tokens == The official list of tokens available to servers and client is maintained by IANA, and it includes: br – Brotli, a compression algorithm specifically designed for HTTP content encoding, defined in RFC 7932 and implemented in all modern major browsers. compress – UNIX "compress" program method (historic; deprecated in most applications and replaced by gzip or deflate) deflate – compression based on the deflate algorithm (described in RFC 1951), a combination of the LZ77 algorithm and Huffman coding, wrapped inside the zlib data format (RFC 1950); exi – W3C Efficient XML Interchange gzip – GNU zip format (described in RFC 1952). Uses the deflate algorithm for compression, but the data format and the checksum algorithm differ from the "deflate" content-encoding. This method is the most broadly supported as of March 2011. identity – No transformation is used. This is the default value for content coding. pack200-gzip – Network Transfer Format for Java Archives zstd – Zstandard compression, defined in RFC 8478 In addition to these, a number of unofficial or non-standardized tokens are used in the wild by either servers or clients: bzip2 – compression based on the free bzip2 format, supported by lighttpd lzip – compression based on the free lzip format, supported by wget and Links lzma – compression based on (raw) LZMA is available in Opera 20, and in elinks via a compile-time option peerdist – Microsoft Peer Content Caching and Retrieval rsync – delta encoding in HTTP, implemented by a pair of rproxy proxies. xpress – Microsoft compression protocol used by Windows 8 and later for Windows Store application updates. LZ77-based compression optionally using a Huffman encoding. xz – LZMA2-based content compression, supported by a non-official Firefox patch; and fully implemented in mget since 2013-12-31. == Servers that support HTTP compression == SAP NetWeaver Microsoft IIS: built-in or using third-party module Apache HTTP Server, via mod_deflate (despite its name, only supporting gzip), and mod_brotli Hiawatha HTTP server: serves pre-compressed files Cherokee HTTP server, On the fly gzip and deflate compressions Oracle iPlanet Web Server Zeus Web Server lighttpd nginx – built-in Applications based on Tornado, if "compress_response" is set to True in the application settings (for versions prior to 4.0, set "gzip" to True) Jetty Server – built-into default static content serving and available via servlet filter configurations GeoServer Apache Tomcat IBM Websphere AOLserver Ruby Rack, via the Rack::Deflater middleware HAProxy Varnish – built-in. Works also with ESI Armeria – Serving pre-compressed files NaviServer – built-in, dynamic and static compression Caddy – built-in via encode Many content delivery networks also implement HTTP compression to improve speedy delivery of resources to end users. The compression in HTTP can also be achieved by using the functionality of server-side scripting languages like PHP, or programming languages like Java. Various online tools exist to verify a working implementation of HTTP compression. These online tools usually request multiple variants of a URL, each with different request headers (with varying Accept-Encoding content). HTTP compression is considered to be implemented correctly when the server returns a document in a compressed format. By comparing the sizes of the returned documents, the effective compression ratio can be calculated (even between different compression algorithms). == Problems preventing the use of HTTP compression == A 2009 article by Google engineers Arvind Jain and Jason Glasgow states that more than 99 person-years are wasted daily due to increase in page load time when users do not receive compressed content. This occurs when anti-virus software interferes with connections to force them to be uncompressed, where proxies are used (with overcautious web browsers), where servers are misconfigured, and where browser bugs stop compression being used. Internet Explorer 6, which drops to HTTP 1.0 (without features like compression or pipelining) when behind a proxy – a common configuration in corporate environments – was the mainstream browser most prone to failing back to uncompressed HTTP. Another problem found while deploying HTTP compression on large scale is due to the deflate encoding definition: while HTTP 1.1 defines the deflate encoding as data compressed with deflate (RFC 1951) inside a zlib formatted stream (RFC 1950), Microsoft server and client products historically implemented it as a "raw" deflated stream, making its deployment unreliable. For this reason, some software, including the Apache HTTP Server, only implements gzip encoding. == Security implications == Compression allows a form of chosen plaintext attack to be performed: if an attacker can inject any chosen content into the page, they can know whether the page contains their given content by observing the size increase of the encrypted stream. If the increase is smaller than expected for random injections, it means that the compressor has found a repeat in the text, i.e. the injected content overlaps the secret information. This is the idea behind CRIME. In 2012, a general attack against the use of data compression, called CRIME, was announced. While the CRIME attack could work effectively against a large number of protocols, including but not limited to TLS, and application-layer protocols such as SPDY or HTTP, only exploits against TLS and SPDY were demonstrated and largely mitigated in browsers and servers. The CRIME exploit against HTTP compression has not been mitigated at all, even though the authors of CRIME have warned that this vulnerability might be even more widespread than SPDY and TLS compression combined. In 2013, a new instance of the CRIME attack against HTTP compression, dubbed BREACH, was published. A BREACH attack can extract login tokens, email addresses or other sensitive information from TLS encrypted web traffic in as little as 30 seconds (depending on the number of bytes to be extracted), provided the attacker tricks the victim into visiting a malicious web link. All versions of TLS and SSL are at risk from BREACH regardless of the encryption algorithm or cipher used. Unlike previous instances of CRIME, which can be successfully defended against by turning off TLS compression or SPDY header compression, BREACH exploits HTTP compression which cannot realistically be turned off, as virtually all web servers rely upon it to improve data transmission speeds for users. As of 2016, the TIME attack and the HEIST attack are now public knowledge.
The Business Cloud
The Business Cloud is an API enabled self-service platform, developed by Domo, that provides an array of services like data connection and data visualization. == History == Domo, Inc. was founded in 2010 by Josh James who also co-founded the web analytics software company Omniture in 1996, which he took public in 2006. Domo launched the Domo Appstore, with 1,000 apps with social and mobile capabilities, in 2016. This appstore creates a network of business apps and an ecosystem of companies into a single, integrated business cloud. This decision came after Domo announced a $131 million round of funding from BlackRock. According to the company, the concept behind The Business Cloud is to connect smaller clouds relating to apps or other functional areas of a business into a single business cloud that allows self-service and other social features to customers. == Services == The Business Cloud is offered as a free service, claimed to be the world's first business cloud with Domo appstore as one of its core services. This free package includes all of the Domo's features and functionality including Domo platform, Domo Apps, visualizations, alerts, company directories, org charts, profiles, tasks and Domo Mobile. The Business Cloud allows customers to leverage their preferred cloud as well as on-premises software and monitor all aspects of their business in routine. The company is supported by a $500 million fund from investors all over the world.
Odor source localization
Odor source localization (OSL) is the problem of locating the origin of an airborne or waterborne chemical plume using one or more mobile sensors, typically robots equipped with chemical sensors. The task sits at the intersection of robotics, fluid dynamics and machine olfaction. Chemical plumes in turbulent flows are intermittent and patchy, and most chemical sensors respond slowly and have limited selectivity, so the instantaneous reading available to a moving sensor is a poor proxy for the underlying time-averaged concentration field. Robotic OSL has been studied since the late 1980s and has applications including the detection of gas leaks, search and rescue after industrial accidents, and environmental monitoring of industrial emissions. == History == Robotic odor search emerged in the late 1980s and 1990s, drawing on earlier work in chemical ecology that had described how moths and other insects locate distant pheromone sources. R. A. Russell at Monash University was among the first to build mobile robots that followed chemical trails on the floor and tracked airborne odor plumes. Distributed and multi-robot odor search were investigated by Hayes, Martinoli and Goodman at the California Institute of Technology and EPFL, who studied cooperative plume-tracing on simulated and physical robot swarms. In 2007 Vergassola, Villermaux and Shraiman introduced infotaxis, an information-theoretic search strategy in which a sensor moves so as to maximize the expected information gain about source location, rather than following a chemical concentration gradient; the paper appeared in Nature and prompted substantial follow-up work in the robotics community. From the mid-2010s, multi-rotor unmanned aerial vehicles carrying lightweight chemical sensors became a common experimental platform for OSL research. == Problem formulation == OSL is generally decomposed into three sub-problems: plume detection (deciding whether a chemical signal is present), plume traversal (moving so as to remain in contact with the plume), and source declaration (deciding when the source has been reached). The mathematical difficulty depends strongly on the assumed dispersion model. In laminar or low-Reynolds number flows a Gaussian advection–diffusion model gives a smooth concentration field with a well-defined gradient. In turbulent flows, which dominate most realistic environments, the plume is filamentary: the sensor receives short, randomly spaced bursts of chemical separated by periods of zero signal, and the time-averaged field is not a useful guide on the time scales at which a robot must act. Source-term estimation, surveyed by Hutchinson and colleagues, additionally aims to recover both the position and the release rate of the source from the observed concentrations, often using probabilistic filters. == Biological inspiration == Many OSL strategies are explicitly modeled on the behavior of male moths flying upwind toward a pheromone source. As reviewed by Cardé and Willis, moths combine an upwind surge whenever they detect a filament of pheromone with a wider crosswind cast when contact is lost, producing a characteristic zig-zag trajectory that has been transposed onto mobile robots by several groups. Other biological models draw on the search behavior of dogs and of marine animals such as blue crabs and lobsters, which integrate chemical and bilateral hydrodynamic cues over much shorter ranges. == Algorithms and strategies == === Reactive strategies === Reactive strategies select the next motion as a direct function of the current sensor reading. Chemotaxis steers along the locally estimated concentration gradient, which is effective in laminar plumes but degrades severely in turbulence. Anemotaxis exploits a measured wind direction by surging upwind when chemical contact is made. The bio-inspired cast-and-surge family combines anemotaxis with a deterministic crosswind cast on contact loss, and is the dominant reactive approach for turbulent environments. === Probabilistic and information-theoretic strategies === Probabilistic methods maintain a posterior distribution over possible source locations and choose actions that improve that distribution. The infotaxis strategy of Vergassola, Villermaux and Shraiman selects the move that maximizes the expected reduction in entropy of the source-location posterior, and is effective in regimes where the spatial gradient is unusable. Bayesian source-term estimation extends this idea by inferring both source position and release rate, typically using particle filters or sequential Monte Carlo. === Map-based strategies === Map-based methods build a spatial model of the time-averaged gas distribution from sensor readings collected along the robot's trajectory and search for local maxima in that model. Lilienthal and colleagues describe a family of kernel-based gas distribution mapping techniques in which point measurements are convolved with a Gaussian kernel to produce a spatially extrapolated estimate. Such methods are most useful when the source can be assumed quasi-stationary and the robot is able to revisit locations. === Multi-robot and swarm strategies === Multiple robots searching cooperatively can shorten search times. Cooperative formations spread the sensors across the crosswind axis, making detection of an intermittent plume more likely. Swarm-based approaches, reviewed by Wang and colleagues, deploy larger numbers of simpler agents and rely on collective behavior rather than centralized planning; reported advantages include improved coverage of the search area and the possibility of locating multiple sources in parallel. == Sensors and platforms == Most OSL systems use metal-oxide semiconductor (MOX) sensors, photoionization detectors or electrochemical cells, which trade off sensitivity, selectivity, response time and power consumption. Ishida and colleagues describe how these sensors interact with airflow around the robot body, an effect that motivates careful aerodynamic design and active sampling. Mobile platforms include wheeled ground robots for indoor and structured outdoor environments, multi-rotor unmanned aerial vehicles for open spaces and elevated sources, and autonomous underwater vehicles for chemical plumes in the marine environment. == Notable systems == Among the early demonstrations, R. A. Russell's series of differential-drive robots at Monash University localized volatile sources in still and ventilated rooms during the 1990s. The Smelling Nano Aerial Vehicle reported by Burgués and colleagues used a Crazyflie nano-quadcopter (approximately 27 grams in mass and 10 cm across) carrying a custom MOX gas sensing board, and built three-dimensional gas distribution maps of indoor releases from sweeping flights of less than three minutes. The GADEN simulator, released by Monroy and colleagues, couples three-dimensional dispersion computed from an OpenFOAM CFD solver with models of MOX and photo-ionization gas sensors, and is widely used to test mobile-robot olfaction algorithms in simulation. == Applications == Reported applications include the localization of natural-gas and methane leaks in urban infrastructure, search for chemical contamination after industrial accidents, search and rescue, and environmental monitoring of industrial emissions. Drug- and explosives-detection robots are an adjacent application area, although these typically rely on close-range sniffing rather than long-range plume tracking. == Open challenges == Open challenges identified in recent reviews include the limited speed, selectivity and stability of available chemical sensors; the scarcity of standardized, large-scale benchmarks comparable to those available in computer vision; reliable handling of multi-source environments, where standard single-source assumptions fail; and the integration of OSL with other autonomous-vehicle subsystems such as obstacle avoidance and navigation in three-dimensional turbulent flow.
Enterprise mobile application
The term enterprise mobile application is used in the context of mobile apps created/brought by individual organizations for their workers to carry out the functions required to run the organization. It is the process of building a mobile application for the requirements of an enterprise. An enterprise mobile application belonging to an organization is expected to be used by only the workers of that organization. The definition of enterprise mobile application does not include the mobile apps that an organization create for its customers or consumers of the products or services generated by the organization. == Example == An organization, whether for-profit or non-profit, may create a mobile app for its members to track inventory levels of supplies they distribute to their target communities or materials used in product manufacturing. Such a mobile app comes under the definition of enterprise mobile application. However, the same organization may also create another mobile app to sell their products to end users or spread awareness of their services to various communities, and that mobile app would not come under definition of enterprise mobile application. == Enterprise mobile solution providers == Enterprise Mobile solution providers create and develop apps for individual organizations that can buy instead of creating the apps themselves. Reasons for Organizations buying the apps include time and cost savings, technical expertise. Today Enterprise Mobility is playing track role for enterprise transformation. Today, enterprises needs productivity is a fast way. Enterprise mobility helps business owners to build their work in a progressive way by assisting enterprise mobility solutions.
Multiple satellite imaging
Multiple satellite imaging is the process of using multiple satellites to gather more information than a single satellite so that a better estimate of the desired source is possible. Something that cannot be resolved with one telescope might be visible with two or more telescopes. == Background == Interferometry is the process of combining waves in such a way that they constructively interfere. When two or more independent sources detect a signal at the same given frequency those signals can be combined and the result is better than each one individually. An overview of Astronomical interferometers and a History of astronomical interferometry can be referenced from their respective pages. The NASA Origins Program was created in the 1990s to ultimately search for the origin of the universe. The theory that the Origins Program is based on is: since light travels at a constant speed until it is absorbed by something; there is still light that was part of the first light ever created traveling about the universe and ultimately some of that light is coming in the general direction of Earth. So a satellite system capable of collecting light from the beginning of the universe would be able to tell us more about where we came from. There is also the constant search for life in other worlds. A satellite system using the interferometric technologies mentioned above would be able to have a much higher resolution than any of the current deep space imaging systems. == Future == NASA is currently focused on the Vision for Space Exploration and has reduced current funding for scientific unmanned space exploration in favor of human exploration. These budget cuts have slowed the multiple satellite imaging development and relevant scientific missions as Project Prometheus and Terrestrial Planet Finder have ended as well but research continues.
ZeroPC
ZeroPC was a commercial webtop developed by ZeroDesktop, Inc. located in San Mateo, California. ZeroPC has been called a personal cloud OS. It mimicked the look, feel and functionality of the desktop environment of a real operating system. The software was launched in September 2011 through Disrupt SF 2011 event and recently selected to the finalist of SXSW 2012 in Innovative Web Technology category. ZeroPC is web-based and required a Java applet to operate bundled productivity tool Thinkfree. The web applications found on ZeroPC are built on Java in the back end. Features included drag-and-drop functionality, cloud dashboard and personal cloud storage meta services. ZeroPC belonged to a category of services that intended to turn the Web into a full-fledged platform by using Web services as a foundation along with presentation technologies that replicated the experience of desktop applications for users. ZeroPC aggregates content so users can easily access, transfer and share whatever content they want, using a web browser from any device. Its meta-cloud layer supports Dropbox, Box, SugarSync, OneDrive, 4Shared, Google Drive, Evernote, Picasa, Flickr, Instagram, Facebook, Twitter, and Photobucket. ZeroPC Cloud OS platform also provides extensive APIs for iOS and Android App developers. Some of the features found on ZeroPC are: File sharing, Webmail, Cloud Content Navigator, Instant messenger, Sticky Note, Audio/Video Player and Office productivity applications. ZeroPC 2.0 platform ran on AWS for free and paid users. Its platform is licensable to Telco and ISV for commercial purpose. Their clients are SFR, SK Telecom, Hancom and others. As of June 1, 2017, ZeroPC's servers were switched off completely, and ZeroPC is no longer in service since its parent company, NComputing, had launched Virtual Desktop Service in the cloud (AWS) to public. == Browser and Platform Compatibility == The ZeroPC web desktop was compatible with Mac OS X and Microsoft Windows platforms. It is certified to operate on Safari 6.0, Firefox 15.0.1, Google Chrome 22.0.1229.79 m and Internet Explorer 8 and 9. The ZeroPC front end user interface executes entirely within a web browser (see above) and uses HTML, some features of HTML5, JavaScript, AJAX and an optional Java plug-in. == Security == All communication between the ZeroPC front end user interface and the ZeroPC back end servers is encrypted using SSL (HTTPS) protocol. Furthermore, any content stored in the ZeroPC server-side repository is also encrypted using 256-bit Advanced Encryption Standard (AES-256) by Amazon S3 on AWS. ZeroPC users could connect their ZeroPC profile to other storage services such as Dropbox and Box. This connection allows the ZeroPC user to fully manage their content stored in these other storage services. To establish the connection ZeroPC rigorously adhered to the Oauth implementation provided by the target storage service. Upon completion of the Oauth process, ZeroPC stores the relevant access token in the user's profile. This token, along with all other sensitive password related data was encrypted using AES 256-bit key size. == Implementations == As noted above, the ZeroPC platform was hosted on Amazon Web Services infrastructure and is available to the general consumer. A user was allowed to sign up by selecting one of three account plans including a no-cost option. The ZeroPC could also be white-labeled for organizations wishing to provide this functionality to their own users. The white-label options include managed hosting on Amazon Web Services infrastructure and also installation within the organization's IT infrastructure. == User Access Points == The ZeroPC infrastructure provided user access to content and features in several different ways. As described in this article the user can access their information by signing into the ZeroPC web desktop. Additionally, ZeroPC offers native applications designed to run on popular mobile devices including smartphones and tablets. == Leadership == ZeroPC was founded by Chief Executive Officer, Young Song, an entrepreneur who previously founded NComputing, a $60 million venture-backed company. He also co-founded eMachines, Inc., a low-cost computer brand (later acquired by Gateway).
Flexidraw
Flexidraw is a 1985 graphics computer program published by Inkwell Systems. == Gameplay == Flexidraw is a graphics program that allows users to produce drawings using a light pen and print them. == Reception == Roy Wagner reviewed the product for Computer Gaming World, and stated that "Of the many graphics programs available Flexidraw is certainly the best supported by it's [sic] parent company."